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Preface 


This manual is one of a series designed to instruct and guide you in using the SPERRY 
UNIVAC Operating System/3 (OS/3). This document describes the distributed data 
processing (DDP) concepts and facilities. 


This manual is divided into the following parts: 


PART 1. DISTRIBUTED DATA PROCESSING CONCEPTS 


Defines DDP, gives background definitions, and discusses the function of current 
and future DDP products. Part 1 is designed for the site administrator who needs 
to know how SPERRY UNIVAC DDP products fit together and for the programmer 
who wants to examine the concepts behind the products. 


PART 2. DISTRIBUTED DATA PROCESSING FACILITIES 
Describes in detail the use of: 


the DDP transfer facility, which sends files and jobs from one computer to 
another; 


the DDP file access facility, which enables users to access and process files on 
remote computer systems and write applications programs that can 
communicate with other applications programs on remote OS/3 systems; and 


the IMS DDP transaction processor facility (IMS DDP), which enables users to 
process IMS transactions at a remote OS/3 computer. 


Part 2 is designed for the person who uses the DDP facilities. 
PART 3. APPENDIXES 


Explains DDP commands and logging methods; show how to enter DDP messages 
as a batch stream and how to define your ICAM network for DDP. These 
appendixes are designed as reference tools. Appendix D is a special appendix 
summarizing DDP for the system operator; it should be removed from this manual 
and added to the operations handbook. 








UP-8811 Rev. 1 SPERRY UNIVAC OS/3 Preface 2 
DISTRIBUTED DATA PROCESSING 


=# GLOSSARY 
Defines DDP terms. 
The following publications are referenced in this manual: 


w# OS/3 interactive services commands and _ facilities user guide/programmer 
reference, UP-8845 


m OS/3 general editor user guide/programmer reference, UP-8828 
= OS/3 spooling and job accounting concepts and facilities, UP-8869 
= OS/3 Assembler user guide, UP-8061 


mw IMS action programming in COBOL and basic assembly language (BAL) user guide, 
UP-9207 


m IMS action programming in RPG II user guide, UP-9206 


IMS system support functions user guide, UP-8364 
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1. An Introduction to Distributed 
Data Processing 


1.1. DISTRIBUTED DATA PROCESSING AS A MANAGEMENT CONCEPT 


Distributed data processing (DDP) is not a hardware or software product. It’s a way to 
manage data within an organization. Instead of centralizing all your data at one location, 
you distribute it to the sites where it's needed most. Then you use electronically linked 
computers to move data from one site to another or to access or change it from a 
remote location. 


Because the term distributed data processing means different things to different people, 
the first thing we'll do is define what Sperry Univac means by the term. 


1.2. WHAT IS DDP? 


We're all familiar with how businesses grow. At first, there’s just the owner, who 
makes all the decisions and has all the responsibility. He buys a building, orders 
supplies, hires some workers, supervises what they do, and markets his product. He’s 
his Own personnel manager, inventory supervisor, and salesman all rolled into one. 
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But, as his business grows, he can’t keep control of everything himself. He needs help. 
So he takes partners, and they in turn hire department managers. Maybe there’s a new 
branch with its own managers. All these people are making decisions — responsible, 
serious business decisions that affect the whole enterprise. The original owner no 
longer has total control. In other words, decision-making responsibility is distributed 
across many managers. 











The business is kept on course through communication. Information flows up and down 
the management ladder. Department managers keep their superiors informed of their 
actions. People in the president's office exert central control. 


The business communication process is a lot easier since the introduction of computers. 
Managers have rid themselves of mountains of files. Reports that used to take days to 
research and type now take only minutes. 
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But, until recently, computers had a serious disadvantage. Often, there was only one of 
them in a company and everybody had to use the same one. That meant that, if you 
were the branch manager in San Francisco with your headquarters in New York, you 
had to send all your raw data through a terminal to headquarters, then request reports 
back through the same terminal. To keep communications costs down, you may have 
communicated only at night. You may have waited a day or more for reports. And you 
didn't have control over the most important management tool of all — your own data. 





Less expensive computers changed all that. Now you can put small computers in 
branches so local managers can control their own data. But what about sending 
information up and down the management ladder? With computers scattered all over 
the company, central managers might not have easy access to the data they need to 
keep everything coordinated. 
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To get the administrative advantages of the local computers while at the same time 
keeping central control, you need a distributed data processing (DDP) system. In a DDP 
system, your independent, local computers are linked so that any computer can access 
another's data or send jobs to it. Just as administrative responsibilities in a large 
company are distributed over a number of managers, so in a DDP system jobs and data 
are distributed over a number of computers. And just as those managers coordinate 
their work through communication, in a DDP system computers coordinate their work to 
access jobs and data on any other computer in the system. 











We can look at a DDP system in three different ways. First, it has a physical aspect: 
DDP links independent computers. Second, it has an administrative aspect: DDP 
distributes both jobs and data over a number of linked computers. Third, it has a 
functional aspect: DDP forms a layer between you and the communications network. 
Let's examine each of these aspects in detail. 
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1.2.1. DDP Links Independent Computers 


A DDP system contains at least two computers capable of independent processing. 


They are linked together through telecommunications so that each can use the other's 
capabilities and data. 


Computers work as equals in DDP. That means that any computer in the system can 
ask for data from the other, and any can send a job to another. 
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At any time, of course, one computer may be in charge, controlling, for instance, the & 
copying of a file. But the computers may switch roles for different jobs. That's different 

from a master-slave relationship, in which one piece of hardware is always in charge 

and the other always does its bidding. 
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The joined computers have independent operating systems. They can communicate and 
process transactions independently. But they can also be joined as equal hosts — not 
terminals — in a DDP system, allowing each computer to perform the job it does best. 
Thus, work is distributed over several computer hosts. 


1.2.2. DDP Distributes Both Jobs and Data over a Number of Hosts 


What is distributed in a DDP system? First, jobs. You can send a job to any other host 
in your DDP system and get the results back just as if your own host had done the job. 
Second, data gets distributed. You can put files on the host where they’re needed 
most, but others can get records from them or copies of the whole file. 
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1.2.3. DDP Forms a Layer between You and the Communications Network 


The third way to view DDP is to look at the function DDP products have in your 
computing system. DDP is that layer of software products and their associated 
hardware devices that lies between the user and a communications network. Current 


products in the layer let you: 
m ~=send files and jobs anywhere in your system; 


™ access and process files anywhere in your system; 


™ write programs that can communicate with other programs anywhere in your 


system; and 


™ use your information management system (IMS) action programs to access records 


on a remote host. 


More products will follow. 


HOST A HOST B 


APPLICATION APPLICATION 
NETWORK NETWORK 
PHYSICAL PHYSICAL 




















1.2.4. DDP Definition Summarized 


DDP is a computer management concept giving local managers control over their data 
and jobs, while at the same time allowing central access to all data. Local computers 
that normally operate independently are linked together through telecommunications so 
that an operator on any Series 90 or System 80 computer can access data on any 
other Series 90 or System 80 computer or send jobs to it. Sperry Univac makes a DDP 
system work for you by providing DDP products that form a layer of service between 


you and the communications network. 
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1.3. REQUIREMENTS FOR A DDP SYSTEM 





The two requirements for a DDP system are: 


1. Two or more computers must be logically separate. Each host must have an 
operating system so it can function independently. 


2. An electronic link must join the hosts so they can work cooperatively on the same 
project. This link makes the capabilities of each host available at any host. It lets 
you distribute projects across different hosts. 


In addition to these requirements, Sperry Univac gives you a bonus. We're using the 
same set of commands to perform DDP tasks on different computers. Identical 
commands achieve identical results anywhere in the system. 







CREATE 
SUBMIT 
PURGE 











CREATE 
SUBMIT 
PURGE 





DDP REQUIREMENTS 


@ Electronic Link 
@ Geographical Separation 
m= Common Command Language 


1.4. WAYS TO JOIN COMPUTERS IN A DDP SYSTEM 


A DDP system contains at least two computers capable of independent processing. But, 
some ways to join computers don’t meet the DDP requirements. 


lf the computers have no links, if the link isn’t electronic, or if only slave terminals are 
joined, you don’t have DDP. 
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a. {ndependent computers with no link 
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b. Independent computers whose link is not electronic 
' 





C. A variety of processing devices linked to a single computer 


HARDWARE CONFIGURATIONS - That are not DDP 
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Now let’s see what a DDP system looks like. You'll recognize the configurations right 
away. They're the same forms you find in any communications network that joins 
nodes. But there is a difference. A communications network joins both hosts and 
terminals. Since a DDP system is a subset of a communications network, only 
independent hosts are joined, though of course those hosts may themselves have 
terminals. 
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HARDWARE CONFIGURATION USING DDP 


So if you already have a communications network, you won't have to make any 
changes in it when you move to DDP. 
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A programmable terminal is the simplest form of independent computer. So, the 
simplest DDP configuration is a link between a processor and a programmable terminal. 
For instance, a SPERRY UNIVAC 90/30 System processor and a programmable SPERRY 
UNIVAC UTS 400 Universal Terminal System form a simple DDP configuration. 


90/30 SYSTEM 
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A MINIMAL DDP SYSTEM 


Although the UTS 400 is normally used as a terminal to a larger computer, it is capable 
of independent processing. Once its programs are loaded from the 90/30 processor, it 
can store and call them with no further help. 


The star is one of the structures most used in DDP, just as it is in communications 
networks. 
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A STAR SYSTEM - Involving a ‘hierarchical’ relationship among hosts 
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Star structures are hierarchical. A central host controls the system. Subordinate, though 
still independent, hosts have links to the central computer but not to each other. It’s 
important to realize, though, that the DDP system itself treats all hosts as equals. Each 
can request data from the others. The central host, in addition to its other functions, 
switches messages from one host on a point of the star to another. 


You may make the central host the largest or make it monitor the functions of the other 
hosts. But you may also decide differently. For instance, your headquarters computer 
could be on one of the points, and the central host could be a small computer mainly 
managing traffic. This structure frees the headquarters computer from. traffic 
management. 
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A STAR SYSTEM - With the largest computer on one of the points 


A star structure with many points transfers messages rapidly, since each message gets 
to its destination with no more than one intervening host. Fast communication makes 
the star efficient. 
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DDP configurations can also use the ring form of communications. 
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INDEPENDENT HOST 


A RING SYSTEM 


The ring is nonhierarchical. There’s no central traffic manager. Each host communicates 
directly with its two contiguous hosts. Communications to the more remote hosts go 
through each intervening host. Thus communications are slower. For this reason, the 
ring is less efficient than the star. You might want to use it, though, if line costs are 
less for a ring than for a star structure. 


Of course, you can combine these types. And most DDP systems will. A tree structure 
can combine star and ring structures. A single host may be in star or ring configuration 
with other hosts in addition to being connected to still other hosts and configurations. 
The important thing is that DDP treats all hosts in the network as equal. 
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A TREE SYSTEM 
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So what do these various DDP structures mean to you? They mean you can have 
whatever configuration of hosts your company needs to process data efficiently. 





1.5. HOW DDP EVOLVED 


Data processing systems have evolved from centralized to decentralized to distributed. 
And distributed processing itself didn’t emerge instantly. Instead, it evolved slowly in 
response to user needs. Distributed systems are well-suited to today’s management 
needs. 


1.5.1. Definitions of Centralized, Decentralized, and Distributed Systems 
w A centralized computer system is a central processor performing varied tasks for 


many users. It generally combines batch processing with electronically connected 
terminals that send and receive data but don’t process it themselves. 


r 






A CENTRALIZED SYSTEM - A central computer and its terminals 


= A decentralized computer system has several different computers, either large or 
mini. These computers are not connected as equals, where each seeks data from 
the other. Instead, they operate independently. 








A DECENTRALIZED SYSTEM - Independent computers with no electronic link 
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Computers in a decentralized system may be temporarily connected to work on the 
same task. But unless they’re connected as equals, they're not in a DDP system. For 
instance, nine-thousand remote (NTR) connects the SPERRY UNIVAC 1100 System and 
the SPERRY UNIVAC 90/30 System so that the 1100 system is always the master and 
the 90/30 system is always the slave. They can’t change roles with NTR. So NTR isn't, 
strictly speaking, a DDP product. 






MASTER 





A DECENTRALIZED SYSTEM - Not a distributed system; NTR doesn’t join the computers as peers 


= @6©A distributed computer system combines the electronic link of the centralized 
system with the independent computers of the decentralized system. Functions 
within the computers can cooperate on the same task, and any computer in the 
DDP system can initiate or control a particular task. 


1 


A DISTRIBUTED SYSTEM - With electronic link between two independent computers 
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1.5.2. The Evolution from Centralization to Decentralization to Distribution 


Because of the cost of the earliest computers, the limited number of people trained to 
operate them, and specialized site requirements, the earliest data processing systems 
were centralized. Very few users could justify the cost of multiple systems. Gradually, 
however, decentralized and then distributed systems evolved from centralized ones. 


Decentralized systems evolve from centralized ones when you add an independent 
computer that’s not connected to the old one. This new computer may be small, or it 
may be as elaborate as the central system. 





























































































































EQUALS 


A DECENTRALIZED SYSTEM 
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Decentralized systems become distributed systems when you join the independent 
computers as equals. Each of the joined computers must be able to access data on any 
other. 






















































































































































































A DISTRIBUTED SYSTEM 


1.5.3. Hardware and Communications Developments Leading to DDP 


Centralized systems developed for a very good reason: cost. The original computer 
hardware cost so much that companies could generally justify the cost of only one 
computer and had to keep it running constantly to realize savings over manual methods. 
But the history of computer hardware costs is one of continually declining prices. Using 
almost any standard of measure (units of main storage, throughput), hardware costs 
only about 10 percent of what it did 10 years ago. And experts project the cost will fall 
to about one-tenth of its present amount over the next decade. 
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In the USA, the cost of computer communications has also fallen, but not as much as 
computer hardware costs. 
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HARDWARE AND COMMUNICATIONS COSTS — 1960 TO 1985 


Because communications costs in both the USA and Europe are controlled by the 
telephone system, future costs are uncertain. Many companies communicate vast 
amounts of raw data from terminals to a centralized computer. It may be cheaper for 
them to do some processing at the original site on relatively inexpensive hardware, and 
then to communicate less data. In many cases, the lowered communications costs more 
than pay for the new computer. 


Many companies already have small compyters in the field, sending back reduced data 
through methods such as NTR. But as hardware costs continue to fall and as the field 
computers become more powerful, it makes less sense to use the field computers 
simply as terminals to a central computer. With DDP, computers can send jobs to each 
other during busy periods and can access facilities they don’t have. At the same time, 
they can continue to send back processed data to a headquarters computer and to 
perform strictly local functions. Linking hosts saves money because the demand for 
excess Capacity at each site during busy periods disappears. 
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@ You may decide to structure your DDP network with a main computer and subsidiary 
hosts. 
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Or you may do away altogether with a main computer and rely wholly on the combined 
capacity of your hosts. 


| & SYSTEM 80 90/30 SYSTEM 


SYSTEM 80 





90/30 SYSTEM SYSTEM 80 


Whichever you choose, Sperry Univac offers you a range of hardware and software 
products to ensure that your system meets your demands. 
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1.6. A BRIEF LOOK AT DDP PRODUCTS 





The available DDP software products are: 
@ The DDP TRANSFER FACILITY 


It allows you to send files and jobs between OS/3 computers. This facility enables 
you to inquire about records on another OS/3 computer or copy its files and 
update them, using simple English-based commands. 


= The DDP FILE ACCESS FACILITY 
It enables you to access and process files on remote hosts and write application 
programs that can communicate with other application programs on remote OS/3 
systems. 


= The IMS DDP TRANSACTION PROCESSOR FACILITY 


It enables you to process IMS transactions at a remote OS/3 computer in three 
different ways: 


1. Directory routing — 
whereby the terminal operator can enter a transaction code at the primary IMS 


center — that locates the transaction at a particular remote site and processes 
it. 





2. Operator routing — 


whereby the terminal operator can enter a special character — that locates the 
transaction at a remote site and process it as in the directory routing manner. 


3. Action program routing — 


whereby the terminal operator can initiate a transaction at a primary IMS center 
via an action program. 


Right now, these products can only be used in OS/3 systems. In the near future, 
however, enhancements of DDP facilities will enable you to link your OS/3 system with 
non-OS/3 systems. 
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2. Advantages of Distributed 
Data Processing 


2.1. OVERVIEW 


SPERRY UNIVAC DDP products help you take advantage of recent computer 
developments that increase responsiveness and lower costs. The advantages of DDP 
deserve close examination. 


2.2. DDP LETS MANAGERS GET DATA FASTER AND MORE EASILY 


Studies indicate that efficiency increases when a manager has control over all the tools 
necessary to make decisions. Computerized data is a vital tool. Under a centralized 
computing system, managers may not have immediate access to their own records, 
which are compiled and stored elsewhere. Special reports may take longer to complete 
than they did under older, manual methods. And managers may not welcome new 
centralized computing functions, since such functions can mean loss of control. 
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Under a DDP system, however, local managers control the local computing site, the 
personnel, and the data. Increased communication between managers and data 
processing people can result in better services for local needs. Thus, local managers 
find themselves using more of the services the computer can perform. 





2.3. DDP SUPPORTS THE ORGANIZATIONAL STRUCTURE OF YOUR COMPANY 


Centralized computer systems make sense in a centralized organization. A centralized 
system, for example, may use remote terminals to collect raw data from branches, and 
use those same terminals to send back directions from the central, decision-making 
group. If the only managers with authority are at central headquarters, it makes sense 
for them to control all computer data. 


Similarly, a decentralized system works well in a decentralized organization. If a 
manager's only responsibility to headquarters is a once-a-year profit report, and if his 
branch has little contact with other branches, it makes sense for him to have a strictly 
local computer system. 


But most business organizations don’t fall into either of these categories. Instead, they 
use what we might call a distributed management system, whereby decisions are made 
at different management levels. A distributed data processing system offers the ideal 
compromise: central coordination of, and access to, data processed and located at 
decentralized sites. Distributed organizations avoid too much central control on the one 
hand and every man for himself lack of coordination on the other. Local managers 
control local data, but central managers can quickly access it. 


And the SPERRY UNIVAC DDP products minimize problems in sending data between 
hosts whose basic structures are quite different. 
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2.4. DDP LOWERS COSTS 


As we mentioned earlier, the price of computer hardware has fallen over the past 10 
years to about 10 percent of its original price. And future dramatic reductions are 
anticipated. Communications costs, on the other hand, have decreased much less 
rapidly than hardware costs, and future trends are unpredictable. If you install a central 
computer with many remote terminals that send raw data to it, Communications costs 
may be very high. But if, instead, you process that raw data on a small computer at the 
remote site and then send just a summary, communications costs are bound to be less. 


DDP may also decrease the load on your central computer and increase throughput. The 
computer needs to spend less time in switching among competing jobs and can devote 
more resources to accomplishing tasks. This may allow you to retain your present 
computer rather than having to purchase a larger one. 


DDP also lets your organization share resources. A department that can gain access to 
a large computer in another branch may not need a large computer of its own. Through 
DDP, occasional users can access large systems promptly and efficiently as needed, 
avoiding demands for a larger local system. 


DDP may also help you control personnel costs. Let’s say you're planning to put 
independent computers at five different sites in your company. In the past, that might 
have meant a 500 percent increase in data processing personnel. But since DDP makes 
communications and coordination among those hosts faster and easier, you may be able 
to centralize skilled personnel and have smaller staffs of less skilled persons at the 
remote sites. Using DDP products, the central staff may be able to do a great deal of 
the program development and testing that otherwise would have been done at the 
remote sites. 
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2.5. DDP COMMANDS ARE THE SAME THROUGHOUT THE SYSTEM 


Sperry Univac is developing a common DDP command language for use with all Series 
90 and System 80 systems. This command language lets operators on all systems use 
an identical set of commands to achieve identical results, no matter what computer they 
use. These commands are discussed in Part 2 of this manual. 


The common DDP command language is easy to learn and use. It gives operators and 
programmers a tool that’s portable from one computer to another. The common set of 
commands doesn’t eliminate job control language, but it does mean that the commands 
the operator uses on the remote host are the same as the commands on the local host. 


2.6. DDP HELPS YOU SAFEGUARD YOUR DATA 


Some companies now make copies of files to send to a remote site to guard against 
the total destruction of records at one site. DDP can make this task easier or make the 
files more readily accessible. You can use DDP to make copies of your files on a remote 
host. Then, if files are destroyed, they can be accessed immediately on the remote host 
or recopied from the remote host. Thus, an accident or failure at one host doesn’t 
destroy vital company data. 
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2.7. DDP HELPS YOU CONSERVE YOUR STORAGE FACILITIES 


By being able to access and process remotely located files, DDP helps you conserve 
your storage facilities. A file that is seldom used at a particular site need not occupy file 
space at that site. Instead, whenever that file is needed, it is simply accessed through 
the DDP file access facility. 


2.8. DDP HELPS YOU MAINTAIN PROGRAM CONTROL BETWEEN REMOTE 
SYSTEMS 


By providing the ability to have programs initiate and communicate with one another, 
DDP allows you to write programs that control the execution of other programs at 
remote sites. Thus, an application that requires several programs to be executed in a 
sequence determined by processing events, can now be programmed to function 
automatically. That is, after the first program is initiated, it initiates the second, which in 
turn could initiate a third and fourth program, and so on. The communicating programs 
can be located on the same host or distributed among all the host systems in the DDP 
network. 
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3. Computer Concepts Behind 
Distributed Data Processing 


3.1. USING SPOOLING IN DDP 


Spooling is vital to a DDP system because it lets hosts store DDP data or output until 
devices are available at the destination host. Without spooling, you'd have to make sure 
that, for instance, any time you expect output back from a remote host, your printer or 
punch must be free. With spooling, output from a remote host goes to your spool file 
to wait until the device is available. 
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3.2. DISPLAYING MESSAGES 

Display messages tell you about your job. They may tell you that your job has been 
successfully submitted to the DDP network or that the remote host has completed it. 
The DDP software displays messages at: 

m= =the terminal, workstation, or system console where you. entered the command; 

w the log of the host originating the command; 

m the system console of the host originating the command; 


m the log of the receiving host; or 


m the system console of the receiving host. 


DOPSB2 ELF @82 COPY COMMAND COMPLETED WO= 698562 11:42:35 





3.3. AUTOMATIC LOGGING AND ACCOUNTING METHODS WITH DDP 


All DDP local and remote activity is automatically logged and sent to the central site 
printer for your reference. See 7.1.1. 


Logging and job accounting for DDP is described in spooling and job accounting 
concepts and facilities, UP-8869 (current version). 
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3.4. HOMOGENEOUS VERSUS HETEROGENEOUS SYSTEMS 


Computer hosts form a homogeneous DDP system if they use the same operating 
system. Thus a 90/30 computer and a System 80 computer form a homogeneous 
system, since both use OS/3. A 90/30 computer and an IBM System 34 computer, 
however, form a heterogeneous system, since the first uses OS/3 while the second 
uses a non-OS/3 operating system. 


Current SPERRY UNIVAC DDP systems are only homogeneous. Heterogeneous systems 
will come later. Then you'll be able to connect Series 90 and System 80 computers 
with computers from other manufacturers. 


3.5. COMMUNICATIONS REQUIREMENTS FOR DDP HOSTS 


DDP requires electronic communications and Sperry Univac is using its distributed 
communications architecture (DCA) to implement DDP. In its present form, DDP requires 
the following communications software products: 


m= = =§=integrated communications access method (ICAM); and 


= DCA termination system, or public data network (PDN). 


3.6. ENTERING COMMANDS TO A REMOTE HOST OR TO YOUR LOCAL HOST 


You can enter DDP commands at the system console, a terminal, or a workstation. 
Normally, you'll use a terminal or workstation that is not dedicated to DDP. 


Some DDP functions take a long time to execute. For instance, you may want to copy a 
very large file. Or you may want to start a program on a busy host and then have to 
wait to establish a connection. Fortunately, your terminal is not reserved for DDP during 
the entire DDP operation. Once you have entered the DDP commands to start your 
function, you may perform other tasks after the DDP command you entered has been 
accepted. 


DDP commands aren't reserved just for remote tasks. You can also use them to 
perform local tasks as well. You simply use your own host's identification number for 
the receiving host. You may not want to do that often, since only a limited number of 
local tasks can be performed through DDP commands. But if you suddenly need to 
perform a task such as a job start or a file copy while working with DDP, you can 
simply use DDP commands to do the job. 
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4. The Current Products 


4.1. OVERVIEW 

Three DDP products are available: 

m SPERRY UNIVAC DDP transfer facility 

m SPERRY UNIVAC DDP file access facility 

m SPERRY UNIVAC IMS DDP transaction processor facility 


This section presents an overview of these products, describing what they do for you. 
Part 2 of this manual explains how you can use these facilities. 

4.2. DDP TRANSFER FACILITY 

The DDP transfer facility allows you to transfer files and jobs between OS/3 computers. 
You can also inquire about the availability of a file or the status of a job on a remote 
OS/3 system. A simple set of English-based commands is all you need to use the file 
transfer facility. 


4.2.1. Sending Files to a Remote Host 


You can copy data files, library files, or individual modules from library files and send 
these files to another host. 


You can transfer files three ways: 
= From a local system to a remote system 
m From a remote system to a local system 


a From a remote system to a remote system 
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You can: 





m duplicate a data base by sending files to a remote host; 

m ~=send a library file of programs to a remote host and run the programs later; 

™ = =©make anew copy of a file that has been updated at another host; and 

= ~=e send files to a remote host for a special project. For instance, an annual report may 
require one-time access to data on several hosts. If many separate points of access 
to those files are needed, the most efficient way to do the job may be to copy all 
the files onto one host and run the report program there. 

4.2.2. Sending Jobs to a Remote Host 

In addition to the file copying described in 4.2, you can also: 

m ~=send job control streams (a form of program module) from one host to another; 

m= start a job on a remote host; 


m send, receive, and respond to messages from a job on a remote host; 


= inquire about the status of your job on a remote host; and 





= communicate with the operator of a remote host. 
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4.2.3. Job Control Language and Device Requirements for Remote Jobs 




































































When you send job control streams to a remote host, you must know details about the 
capacities and devices of your remote host so you can write your job control stream to 
conform to its limits. 


Job streams must be complete to be sent. And once you send them, they may be 
performed in any time sequence — not just in the one you originally intended. So don’t 
send jobs to different hosts if the successful completion of one job depends on the 
prior execution of another. If, for instance, job A sends data to job B, execute both jobs 
on the same host. 


4.2.4. What Happens to Output from Remote Jobs? 


What happens to completed output? Normally, it returns automatically to the sending 
host's spool file. Then it’s printed or punched, according to your instructions in the job 
control stream. In the future, in addition to this automatic return, you will also be able 
to send the output to a third host or send multiple copies throughout the DDP system. 
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4.2.5. Functions You Perform with Remote Jobs 

Jobs are sent to remote hosts for various reasons. For example you can: 

= move a job that’s too large for one computer to a more powerful one; or 

m@ you can move a job needing a particular file to the host where the file resides. 


For example, you may have a centralized inventory file comprised of data from 10 
different sites. Each remote site needs to access or update the file only about once a 
month. But the site where the file resides updates it daily. It wouldn't make sense to 
keep copies of the file at each site and have to update them constantly. Instead, it’s 
more efficient to keep just one file. When the remote sites need to access the file, they 
can submit their jobs through DDP to the site where the file resides. 


Section 8 provides more detailed information on this facility. 


4.3. DDP FILE ACCESS FACILITY 


The DDP file access facility enables you to access and process files residing on remote 
OS/3 systems and write application programs that can initiate and communicate with 
one another. The programs can reside on the same or different hosts. 


4.3.1. Remote File Processing 


You can now access and process remote disk files simply by adding a host 
identification parameter to the device assignment set for that file. DDP will then connect 
your program with the remotely located file. No changes are required in your program. 
Remote file processing eliminates the need for you to copy a remote file on your 
system before you can access and process it. 


4.3.2. Program-To-Program Communication 


You can now write BAL programs that can communicate with one another on different 
OS/3 hosts in your DDP network. You can write primary/surrogate programs that you 
can use to transfer data from one host to another host, elaborate on the data, and then 
send it back to the original host. 


The program that initiates the conversation is called the primary program and the 
initiated program is called the surrogate program. However, the primary and surrogate 
can reverse roles. There is no limit to the number of status changes that can be 
requested between a pair of programs. In addition, up to 255 surrogate programs can 
be initiated by a primary program. 
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All program to program conversations are initiated and controlled by a set of 
consolidated data management macroinstructions embedded in both primary and 
surrogate programs. These macroinstructions enable a program to: 

m ~=establish a conversation with another program (DOPEN); 

™ = §=§6direct a communication to a particular surrogate program (DMSEL); 

= transfer data between programs (DMOUT and DMINP); 


™ transfer primary/surrogate control between programs (DMCTL); and 


=~ ~=©terminate a conversation with a program (DCLOSE). 


4.4. IMS DDP TRANSACTION FACILITY 


The IMS DDP transaction facility lets you process IMS transactions at a remote OS/3 
computer. To use this facility, each OS/3 system must: 


1. include the IMS transaction facility in their operating system; 


2. define a global ICAM network that supports distributed data processing, including a 
LOCAP macroinstruction identifying each IMS system that will send or receive 
remote transactions; 


3. configure a multithread IMS; and 
4. include a LOCAP section in the configuration for each remote IMS system. 


In a DDP transaction, a terminal operator at one IMS system, called the primary IMS, 
initiates the transaction. The primary IMS, through the transaction facility, routes the 
transaction to a remote system where a secondary IMS processes the transaction and 
sends back a response. The remote transaction may be processed by user action 
programs (written in COBOL, RPG Il, basic assembly language) or by UNIQUE (inquiry 
language). There is little difference between the way action programs process a remote 
transaction and the way they process a local transaction. Most IMS features are 
available, including the use of screen format services. 


Continuous output, use of auxiliary devices, and switch messages (SEND function) 
features at the source terminals are unavailable at present. 


The three different ways in which IMS can route a transaction to a remote system are 
explained in the following subsections. 
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4.4.1. Directory Routing 


A terminal operator at the primary IMS enters a transaction code that identifies a 
transaction at a particular remote system. The transaction code and the remote system 
associated with it are defined to IMS in the configuration. The primary IMS routes the 
message to the secondary IMS, where action programs or UNIQUE process the 
transaction. Once the transaction begins, a communications link is established between 
the terminal operator and the remote system. This allows a dialog transaction consisting 
of multiple input and output messages. 


OS/3 IMS 










TRANS- 
ACTION 









TRANSACTION 
DIRECTORY 
ene 





OS/3 IMS 
SENDS 
BACK ACTION 
RESPONSE PROGRAM 


Directory Routing 


4.4.2. Operator Routing 


Operator routing is similar to directory routing. In this case, a special character is 
associated with the remote system, rather than a transaction code. The special 
character is defined in the IMS configuration or at IMS start-up. When the terminal 
Operator enters a transaction code prefixed by the special character, IMS routes the 
message to the secondary IMS, where the transaction is processed in the same manner 
as in directory routing. 


OS/3 IMS 







OS/3 IMS 
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ACTION 
PROGRAM 


Operator Routing 
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4.4.3. Action Program Routing 


The terminal operator enters a transaction code that initiates a transaction at the 
primary IMS system. A COBOL or basic assembly language (BAL) action program at the 
primary IMS issues an ACTIVATE function call to IMS, identifies the remote system in 
its output message header, and generates a message containing a transaction code. IMS 
routes this message to the remote IMS, where action programs process the transaction 
and return a message to the originating action program or its successor. The action 
program at the primary IMS can then return a message to the terminal operator or can 
issue another ACTIVATE call to initiate another remote transaction. 


OS/3 IMS 
















TRANS- 
ACTION [| action 
PROGRAM 


ACTIVATE 


OS/3 IMS 





SENDS 
BACK ACTION 
RESPONSE PROGRAM 


Action Program Routing 
For specific network definition, configurator, and start-up requirements for IMS DDP 
processing, refer to: 


m IMS 90 system support functions user guide and programmer reference, UP-8364 
(current version) 


mw IMS action programming in RPG II user guide, UP-9206 (current version) 


= IMS action programming in COBOL and basic assembly language (BAL) user guide, 
UP-9207 (current version). 
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5. The Future for DDP 


5.1. OVERVIEW 


SPERRY UNIVAC DDP products will come to you in stages. You'll have time to use 
individual products before you need to learn about the next one, and you'll be able to 
try out products before committing yourself to more. 


The following projections are not final product descriptions or commitments to a 
timetable. They are simply an outline of some current Sperry Univac plans. And they're 
not the end. DDP will keep growing to bring you products with capabilities beyond 
these projections. 


5.2. LINKS BETWEEN COMPUTERS WITH DIFFERENT OPERATING SYSTEMS 


In the future, you'll be able to hook up non-SPERRY UNIVAC computers, such as the 
IBM System 34, using DDP products. Other systems will also be considered. 


5.3. EXPANSION OF ALLOWABLE FILE CODING 


DDP currently permits copying only for character-oriented files (EBCDIC and ASCIl). 
Later, this restriction will disappear. You may now use nonencoded characters in your 
system. (Nonencoded characters are bit configurations within ASCII or EBCDIC that have 
no standard meaning. You may use these characters to represent special data in your 
system.) If the file is in ASCII and you're copying it to another computer that uses 
ASCII, there’s no problem. But if either the originating or the destination file, or both, 
are in EBCDIC, DDP translates all nonencoded characters as blanks. However, later, you 
may be able to alter the software to transfer them. 
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6. Statement Conventions 
for DDP Commands 


This manual uses the following conventions to illustrate commands and control 
statements: 


Code capital letters, parentheses ( ), and punctuation marks (except braces, 
brackets, and ellipses) exactly as shown. An ellipsis, which is a series of three 
periods (...), indicates the omission of a number of obvious entries. 


Lowercase letters and terms in commands represent information that you must 
supply. These lowercase terms may contain hyphens for readability. Lowercase 
letters and terms in system response messages represent variables the system 
supplies to you. 


Information within braces { } represents necessary entries. You must choose one. 


Code positional subparameters in the order indicated. Code nonpositional 
subparameters in any order. 


Insert commas after each positional parameter except the last. When you omit a 
positional parameter (or a positional subparameter within a series of parameters), 
retain the comma to indicate the omission. When you omit a trailing positional 
parameter, omit its associated comma also, even when a keyword parameter 
follows. Code positional parameters or positional subparameters in the order 
shown. 


Separate keyword parameters from each other and from positional parameters by 
spaces. This is different from normal OS/3 format. 


Use underlines as indicated in commands. DDP uses underlines, not hyphens, to 
join two words in a parameter. This is different from normal OS/3 format. 


The shaded parameter is selected automatically when you omit a keyword 
parameter or subparameter. In this example, the default for the MODE parameter is 
DIRECT: 


MODE= (8 
WAIT 
INDIRECT 
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= = =©White print on a black background indicates entries in a dialog that the user makes. @ 





= Keyword parameters (nonpositional parameters) are normally entered in the format: 
keyword=value. This manual shows optional keyword parameters in alphabetical 
order, for easy reference. However, you may enter them in any order. 


m Code zero or more spaces before a DDP command. Conclude each command with 
one or more spaces except for the last command on a line, which does not require 
the concluding space. 


= Commands may continue on subsequent lines if the last character on the line to be 
continued is an ampersand (&). In a command, the ampersand may appear only 
where a space may appear, and DDP treats it as the last character on the line. The 
ampersand may follow zero or more spaces and must be followed by at least one 
space before a comment begins. 


m The exclamation mark (!) is the comment character and terminates line scanning. It 
may appear anywhere in a command that a space may appear; it does not have to 
be used only at the end of a command. If you use it in the middle of a command, 
however, be sure to put a continuation character (&) before it so that your 
command may continue on the next line. 


Comments following ampersands do not need the preceding exclamation mark, 
since the ampersand terminates scanning of that line. After an ampersand or an 
exclamation mark, scanning begins again on the next line. 





® Character strings begin and end with apostrophes. Apostrophes (’) within strings 
must be doubled. Parameter values require string format if they contain a comma 
(,), space (A), semicolon (;), exclamation mark (!), apostrophe (’), quote (’’), pound 
sign (#), equal sign (=), or ampersand (&). Note that the exclamation mark and 
ampersand within a quoted string are simply characters within that string. They do 
not have their usual functions as the comment and the continuation characters. 


m When you use a character string as a keyword parameter value, you may continue 
it on the next line by using the pound sign (#) as a concatenation character. The 
procedure is: 


1. Break the character string into two parts. For instance, if you have this 
character string: 


TO=H001::'MOD1,PERSONNELFILECREAD/WRITE),,S' 


break it into the two strings: 


‘MOD 1,PERSONNELFILE(READ/ 
WRITE),,S' 
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Add the concatenation character (#) and the continuation character (&) to the 
end of the first part of the string: 


'MOD1,PERSONNELFILE(READ/'#& 
'WRITE),,S! 


The concatenation character may come immediately after the final character of 
the first part of the string or immediately before the first character of the 
second part of the string. For instance, you might have a long statement in a 
DDP SUBMIT REQUEST command that won't fit on one line. You can continue 
the command on the next line in either of two ways: 


DDP SUBMIT REQUEST='RU CGV, ,0=VSN999 ,N=186309, '#& 
'T=30' HOST=N825 


or 


DDP SUBMIT REQUEST='RU CGV, ,O=VSN999,N=186309, '& 
#'T=30 HOST=N825 


Note that: 


— the concatenation character (#) may follow zero or more spaces, and 
may be followed by zero or more spaces; and 


— to continue a character string on the next line, you must use both the 
concatenation character (#) and the ampersand (&). They may be 
surrounded by any number of blanks and may appear in any order. 
However, if the concatenation character follows the ampersand, it 
must be on the next line, since scanning of the first line terminates at 
the ampersand. 
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7. DDP Network Requirements 


7.1. THE DDP SYSTEM ENVIRONMENT 


To use DDP, all OS/3 hosts in your system must have: 

= = aminimum main storage capacity of 512K bytes (with no resident shared code); 
@ ~§=6 spooling; 

= ~§=ICAM generated with the demand mode interface (DMI); 

™ consolidated data management (CDM); and 

@ ~=interactive services. 


Normally, you also have a terminal or workstation. However, you may enter DDP 
commands at the system console. 


DDP also uses dynamic buffers, but you don’t have to worry about their number or size. 
DDP takes care of that for you automatically. However, some DDP STATUS response 
messages (8.5.1) show you the number and size of buffers being used. The number 
varies with the DDP commands being run. 


7.1.1. DDP Activity Logging 


All DDP local and remote activity is logged in the interactive services log files on the 
systems involved with the DDP activity. This information is provided at the system 
console printer after interactive services shutdown time. 


Figure 7—1 is a typical log printout of a session showing a series of commands that 
were entered by the OPERATOR. At the end of the activity, a DDP STATUS COMMAND 
was entered to provide the status summary shown. Accounting information is given at 
the end of the log printout. 


1LOGON TIME OF EVENT 


LOGON RWK »BU=NO 
DB IS!9 LOGON ACCEPTED AT 13232547 ON 82/05/24, REV 08.0.0S3 tL Lis 22206 


ACTIVITY DURING THIS SESSION BONN 


DDP TALK USERSOPERATOR MESSAGE="START OF ODP TEST®* 
oc DDFOO2 CAi O02 TALK COMMAND ACCEPTED WO=000002 13:34:14 
oO ODFO2Z2 FIR O22 TALK COMMAND COMPLETED WO-O000002 13:34:19 
DOP CREATE FILE=*,TEST»FILE,RES* REG=VTOC 
OE DDFOO2 CA OO2 CREATE COMMAND ACCEPTED WO-000003 13:35:01 
OF DOFO22 FTIR O22 CREATE COMMAND COMPLETED wWO-000003 13:35:05 
DOP COPY FROM="DDPSSTRM,SYSSCLOD,RESsL*® €& 
OG CONTINUE CURRENT DOP COMMAND 
OH? 

DH TC*°OOPSSTRM,TEST PFILE,RES yt * 
OJ OOFO21 CA2 008 COPY COMMAND ERROR WO-OO9CO4 13:236:09 
OK KEYWORD VALUE TO*ODPSSTRM,TESTeFIL IS INVALID 
OL ODFO21 CA2 O20 COPY COMMAND ERROR wO=000004 13:36:10 
QM MISSING TO IDENTIFICATION 
ON DOFO21 CAl1 003 COPY COMMAND ERROR wo=000CO4 13:36:11 
OP COMMAND REJECTED BECAUSE OF ERROR(S)? LISTED ABOVE 
OOP CCPY FROM=*ODPSSTRM,SYSSCLOD,RES L® E 
OQ COKTINUE CURRENT DOP COMMAND 
OA? 

OA TC=*ODPSSTRM,TEST FILE,RES el ® 
06 OOFOO2 CAl O02 COPY COMMAND ACCEPTEO wWO=-000005 13:37:07 
oc o00FO22 FTIR a22 COPY COMMAND COMPLETED WO-000005 13:37:27 
OO PREVIOUS USER FUNCTION KEY NOT PROCESSED 
DOP SUBMIT REQUEST=*FS ,TESTFILERES,L LO® 

GE DDFOO2Z Cal O92 SUBMIT COMMAND ACCEPTED wO->000006 13:38:01 
OF L-DOPSSTRM DDP COMMON TERMINATION RTNE 81/11/29 G2:51 
0G ISS3 FSTATUS FINISHEO, ODOO1 ELEMENTS WERE DISPLAYED 
OH DDFO22 FTIR O22 SUBMIT COMMAND COMPLETED WO-O00CO6 13238214 
OJ PREVIOUS USER FUNCTION KEY NOT PROCESSED 

ODP PURGE FILE=*,TESTFILE,RES*® 

OK ODFOO2 CAI 002 PURGE COMMAND ACCEPTED WO>000007 13:38:44 
OL7IS51 ERASING ENTIRE FILE, PROCEED? CY,N} 

oL. Y 

OM DOFO2Z2 FTR O22 PURGE COMMAND COMPLETED wWO-O00007 13:39:03 
ON FREVIOUS USER FUNCTION KEY NOT PROCESSED 


STATUS OF COMMANDS ISSUED IS REQUESTED 


OOP STATUS USER=REK 

OP ODFOO2 Cal GO2 STATUS COMMAND ACCEPTED wWwO=-000068 13:39:22 
OQ USERID BUFFERS BUF SIZ WoO. COUNT 

QA RK o0002 0009176 ooo002 

OB WeCe# FUNCTION PRIM SECN STARTED COMPLE TE STATUS 

oc 020002 TALK NOD4 NODY 13234237 13234219 TERM NORMALLY 
0D OOCOOS CREATE NOOS NODS 13235:202°13235:05 TERM NORMALLY 
OE 0OCO0S CcoPY NOD4 NOD4Y 13237209 13:37:27 TERM NORMALLY 
OF OOSO06 SUBMIT NOD4 NODS 13238203 13:38:14 TERM NORMALLY 
0G 005007 PURGE NOO4 NODY 13238246 13239:03 TERM NORMALLY 
OH OOCONS STATUS NODS NODY 13239522 8 IN PROGRESS 
Oy ODFO22 FTR O22 STATUS COMMAND COMPLETED WO=009008 13:39:28 


LOGOFF 


LOGOFF 
OK IS73 LOGOFF ACCEPTED AT 13239238 ON 82/05/24 13:39:38 


ACCOUNTING INFORMATION ‘ 


ACSO USER-IO=RWK ACCT NO= LOGON AT 132232246.990 LOGOFF AT 32:46.990 LOGOFF AT 13 a 

: 2 3232: 746.6 23923a",.983 CONNECT TI 206s ? 239: 
ACS1 CPU TIME USEO=00709:28.211 TASK PRIORITY=21 DATE=82705/24 OATE=82/05/24 NUMBER oF Gece ee anocines Sere eee ae 
ACS2 WUMBER OF: COMMANDS=00009 FILES ACCESSED-00004 SyC CALLS=0C097)14 SvC CALLS=0C097)1% TRANSIENT CALLS -0000020° Li: 29:39 


13:34:09 
13234515 
2135 34:29 
222 79:57 


et 00 te oe 98 ts 


Cob tas un ad at tat td 


fe te te C4 on oe OF 


REC RE ER KR RRC ee ER CK REC K ER Ree ec Kc eee ee ce 
(ab Lat bad Gb Ud Ud 


13539219 


EERE ketk@ecrece 





Figure 7-1. DDP Activity Log Printout Sample 
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7.1.2. Host Identification Requirements 

Each host in your DDP network has a host identification (host-id). This is the same 
identification as the label of your DMI LOCAP macroinstruction in your ICAM network 
definition. You must know the host-id to send files to, or otherwise communicate with, 
a remote host. 

The host-id is one to four alphanumeric characters long. The first character must be 
alphabetic. 

7.1.3. Using the DDP Network 


You must always have ICAM and interactive services running to use DDP. So, the first 
things to do to prepare your system for DDP are: 


1. At the system console, enter Cn or Mn to load the appropriate ICAM symbiont, 
where: 
Cn or Mn 
Is the name specified on the MCPNAME parameter in the COMMCT phase 
of SYSGEN, and n is a numeric digit 1 to 9 that identifies the network to 
be loaded. 
The message ICAM READY should appear. 


2. Enter IS at the system console to load interactive services. 


3. You are now ready to use the DDP facilities described in the remainder of this part. 
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8. The DDP Transfer Facility 


8.1. WHAT THE DDP TRANSFER FACILITY DOES FOR YOU 

The DDP transfer facility lets you enter commands at your workstation or terminal to: 
B create a file on a host; 

= copy a file from one host in your system to another; 

= remove a file from a host; 

@ ~=send a job control stream to a host; 

@ ~=run a job control stream on a host; 

= receive the output from your executed job or send the output to another host; 

m= = find out the status of a command, host, job, file, or user in the system; 

m ~=send a request (such as an operator command) to a host; and 


a send a message to a remote operator or user. 
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So, you can perform many tasks on another computer using DDP. 
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But, before you start entering commands, you need some background information. 
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8.2. USING THE DDP TRANSFER FACILITY 


If you're going to enter DDP commands from a terminal, go to 8.2.3. If you're using a 
workstation, go to 8.2.4. If you're entering DDP commands from the system console go 
to 8.2.5. 


8.2.1. File Identification Requirements 


The DDP transfer facility uses a specific form of file identification (file-id). It contains not 
only the name of the file, but also the name of the volume that contains the file (if the 
file isn't cataloged), the module name and type, and the read and write passwords. It is 
a maximum of 74 characters long plus required punctuation marks such as commas, 
slashes, and parentheses for a total of 81 characters. It is similar to the file-id used in 
other OS/3 products such as interactive services, and is always expressed as a 
character string (in apostrophes). 


The file-id format is: 


'tmodule-name],filename[([read-passwrd]/[write-passwrd])],[vol],[element]' 


where: 


module-name 
Is used only when you're sending just one module from a program library file. 
It is the one to eight alphanumeric characters identifying the module. It must 
begin with an alphabetic character. 


filename 
Is always required. It is the same as the name on the // LBL job control 
statement for the program. For disk files, it is 1 to 44 alphanumeric characters 
long. For tape files and logical files (spool files), it is 1 to 17 alphanumeric 
characters long. 


read-passwrd 
Is a password (one to six alphanumeric characters) enabling you to read the 
file. If omitted, the system assumes there is no read password on the DDP 
command. If the file does have a read password that you omit, you won't be 
able to read the file. 
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write-passwrd 


vol 


Is a password (one to six alphanumeric characters) enabling you to write to the 
file. If omitted, the system assumes there is no write password on the DDP 
command. If the file does have a write password that you omit, you won't be 
able to write to the file. 


Is the volume serial number (one to six alphanumeric characters) of the volume 
on which your file resides. Specify this when the file is not cataloged. 


element 


is the type of code one to four alphanumeric characters contained in the 
program module you're sending. In OS/3, we'd normally call this type or 
module-type. But since DDP is designed eventually to connect you with 
non-OS/3 hosts, we're using the word element. 


The element types are the same ones you're familiar with for all OS/3 library files. 
SAT files may have the following types: 


S (source code) 
M (macro) 

P (procedure) 

L (load code) 


O (object code) 


MIRAM files may have the following types: 


F and FC (screen format modules) 
J (saved job control stream) 
MENU (menu modules) 


HELP (help screen modules) 


The default is S (source). 


For MIRAM files, you may create your own element type and identify it with one to 
four characters. (For further information on MIRAM files, see consolidated data 
management concepts and facilities, UP—8825 (current version).) 
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& Table 8—1 gives some examples of complete file-ids. 


Table 8-1. Examples of File-ids 








Type of File 


A cataloged file with no read and ' SITE/3! 

write passwords 

A cataloged file with read and ', SITE/3(XX2674/BENNIS)'! 

write passwords 

A source module from a cataloged ''PROG14, JOBFIL19¢XX4982/RILEY) '#& 
file with read and write passwords Sara aia 

An uncataloged file with a ' SITE/AC/SMPRO) ,VSN149! 

write password but no read password 

An uncataloged file with a ', SITE/A&BCREAD/) ,296410' 

read password but no write password 


8.2.2. Requirements for Using DDP Commands within Your Local Host 









You may use DDP commands to work with files and jobs entirely within your local host. 
& The DDP transfer facility accepts your local host-id as a valid host-id for all commands. 
In addition, DDP commands use your local host as a default if you fail to provide a 
host-id. Thus, if you're working with DDP and must perform a local task, you can 


perform the task with a DDP command. 


8.2.3. Preparing Your Terminal to Enter DDP Commands 


If you're entering DDP commands from a terminal rather than from a workstation or 


system console, you must follow these steps: 
1. Run the GUST program (ML$$G1). 
2. Sign on the terminal. 


Continue with 8.2.4. 
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8.2.4. Logging On (LOGON) 

If you're using a workstation or terminal, enter the LOGON command with your user 
identification. (You don’t need the LOGON statement if you're entering commands from 
a system console.) The format is: 


LOGON user-id 


where: 
user-id 
Is the one to six alphanumeric characters identifying you as a user to the host. 
Example: 
LOGON CHAR 


If the system accepts your LOGON command, it returns a message stating so. 


8.2.5. Entering the DDP Software (DDP) 
If your terminal, workstation, or system console is connected to a DDP network (see 
1.3 and 3.5), you enter DDP software whenever you issue a DDP command. 


8.2.6. Services DDP Performs Automatically 


8.2.6.1. DDP Scans and Forwards Your Commands 

DDP scans your commands and informs you of all detectable syntax errors. (See the 
system messages manual, UP—8076 (current version), for a complete list of all DDP 
messages.) Once the command is correct, DDP accepts it and forwards it to the DDP 
system. 


8.2.6.2. DDP Gives You a Work Order Number to Reference Your Commands 


Once DDP accepts your command, it returns a work order number to you using the 
format: 


DDP@O2 CAI @02 cccccccccc COMMAND ACCEPTED WO=nnnnnn time 
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where: 


ecccccccccc 
Is the name of the command you've just entered. 


nnonnnnn 
Is the work order number of the command. 


For instance, let's say you've just entered the DDP COPY command. DDP responds: 


DDP@@2 CAI @O02 COPY COMMAND ACCEPTED WO=A48107 13:46:02 


Write down the work order number, since error messages use it for identification. If, for 
example, you enter a command that cannot be completed at the remote host, DDP 
informs you of the problem by sending you a message such as: 


DDP@O1 ELH @23 COPY COMMAND ABORTED WO=A48107 13:48:39 


The WO=A48107 is the work order number that DDP returned to you at the time you 
entered your copy command. You may have entered several copy commands; but each 
has a different work order number, so you can tell them apart. 


8.2.6.3. DDP Gives You a Job Name to Reference Your Jobs 


When you enter a DDP SUBMIT FILE command, DDP returns a job name to you with 
which you can cancel the job if you later need to. 


DDP renames all jobs submitted using the DDP SUBMIT FILE= command. The job name 
is eight characters long with the format xxxxyyyy. 


where: 


XXXX 
Is the host-id of the initiated job. 


yyyy 
Is a unique 4-digit number. 


The format for the job name message is: 


DDP@44 EJS @44 jobname JOB SUBMITTED FOR WO=work-order-number time 


As explained in 8.2.6.2, the work order number identifies the command you've entered. 
(In this case, it identifies the DDP SUBMIT FILE command.) 
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8.2.6.4. DDP Sends Messages to You from the Remote Host 

As your command or job is executing on the remote host, it produces messages 
informing you of its status and of any problems encountered. DDP sends you these 
messages at your terminal or workstation. If you are still logged on the system at the 
time the message is produced, it is displayed immediately. If you’ve logged off, DDP 
displays your messages on the system console. 

For a complete list of DDP messages, see the system messages manual, UP—8076 
(current version). 


8.2.7. No Need to Terminate DDP 


You can log off or go on to another task as soon as your command is accepted by 
DDP. 

8.2.8. Entering DDP as a Batch Operation 

DDP is designed as an interactive product. But you can use DDP commands in a job 
control stream. For instance, if it's 4:30 p.m. and you're leaving at 5:00 p.m., you can 
punch cards with DDP commands on them and submit them in the same way you'd 
submit any other remote batch job. Your results and messages are printed at your local 
host. 


Appendix F gives an example of DDP commands entered as a remote batch job. 


8.3. REMOTE FILE COMMANDS: DDP CREATE, DDP COPY, AND DDP PURGE 
There are three remote file commands: DDP CREATE, DDP COPY, and DDP PURGE. 
= The DDP CREATE command establishes a file on a host. 


= The DDP COPY command copies the contents of a file or modules from a file to an 
established file on a host. 


= The DDP PURGE command removes the file or module and all references to it from 
the host. 

8.3.1. Creating a File (DDP CREATE) 

Function and Requirements: 
The DDP CREATE command establishes a file on a receiving host. It allocates 
space for the file and either catalogs the file in your online system catalog or 


records it in your volume table of contents (VTOC). 


The DDP CREATE command is the most complex DDP command. But, once you 
have the file established, copying and using it are easy. 











[ 

- ([éE 
| 
| 
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Follow these requirements for correct file creation: 

= §=©The file name cannot already exist on the receiving host. If you try to use a file 
name already being used, you get an error message. For more information on 
file names, see 8.2.1. 

m Defaults on the file specifications are those of the receiving host. If you do not 
want these defaults, and if your requirements cannot be met through the DDP 
CREATE command parameters, create your file by submitting a batch job 
control stream to the host. (See 8.4.1, the DDP SUBMIT FILE command.) 

= #= The only required parameter is file-id. 


Format: 


peeks (Oe (cea 





saa a | 





ADENSITY=/200 
556 
800 
1600 





ADEVICE_CLASS=/B 
TAPE 


DISKETTE 


FILE_TYPE=/( SEQUENTIAL 
INDEXED 
LIBRARY 





3 
helsing _SIZE= “{ ane 


lea SIZE= __ ao 









mber -blocks/1-9 ase) 


eer ii 4 mamaaeaiaaa DUPLICATES 


[tno cnance 








[are ie } 
eee 


pe 





VARIABLE 
UNDEFINED 


owe _SIZE= Sagres or ersireeneney a2 ae 


ae vTOc | 
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Parameters: 


host-id 
Is one to four alphanumeric characters that name the host you create the file 
on. If you omit the host-id, the command creates a file on your local system. 
For more information, see 7.1.2. 


file-id 
Is 1 to 74 alphanumeric characters identifying your file. For more information, 
see 8.2.1. 


BLOCK_SIZE=({number-of-characters/1-9 ae 
Is the number of characters in a block. If omitted, the default value is 256 
characters. If DEVICE_CLASS=DISKETTE, your maximum block size is 256 
characters. You must specify BLOCK_SIZE if you specify INITIAL_SIZE. 


DENSITY=/200 
556 
800 
1600 
6250 





Is the tape density in bytes per inch (bpi). If omitted, the default value depends 
on the SYSGEN option selected on the receiving host. 


DEVICE_CLASS=(B8i8K 
TAPE 


DISKETTE 
Is the device class that will contain your file. The default is DISK. 





If you specify DEVICE_CLASS=DISKETTE 
a For Series 90 


The diskettes are data set label diskettes and can be used only for 
MIRAM data files. Diskette library files are not supported. Also, 
INITIAL_SIZE must be _ specified, BLOCK SIZE must be 256, and 
RECORD_SIZE cannot exceed 512 characters. 
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For S/80 


The diskettes can be either data set label diskettes or format label 
diskettes. Either type of diskette can be used for MIRAM data files. If you 
intend to use the diskette for library files, then the diskette must be 
prepped as a format label diskette with the following parameters in the 
prep job stream. 


FORM=FLB DNSTY=2 RECSZ=256 
The diskette must be double sided and double density. 


The INITIAL_SIZE parameter of the DDP CREATE command must be 
specified. 


If you specify DEVICE_CLASS= TAPE 


Tapes can be used for MIRAM data files only. 


FILE_TYPE=(SEQUENTIAL 


INDEXED 
LIBRARY 
ED 
file being created. The default is UNDEFINED. 





Is the type of 


A SEQUENTIAL file is one that you access record-by-record, according to the 
order of the records in the file. 


An INDEXED file, such as an IRAM, ISAM, or MIRAM file, is accessed 
according to one or more index keys. 


A LIBRARY file is a collection of program modules. 


An UNDEFINED file may be any type of file. When you create a file as 
UNDEFINED, then copy a file to it, it takes on the characteristics of the 
originating file. There is one restriction, however: if you're copying a source 
library file to an UNDEFINED file that doesn’t have anything in it, POSITION 
must equal SOF. (See 8.3.2.) 


Peo enen ara) number -of -blocks/1-9 ae 





Is the number of blocks of storage to be added to the file whenever you 
extend its size. The number must be greater than zero. The default is 3 
cylinders. 


If you specify INCREMENT_SIZE, you must also specify BLOCK_SIZE. 
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initial -number -of-blocks/1-9 aN) 





Pare e 





Is the number of blocks (1 to 999,999,999) initially allocated to the file. Omit 
this parameter for tapes. The default is 3 cylinders. 


coca 


Is used to create an index for the file on the receiving host. You need one of 
these parameters for each index key (to a maximum of five) that you create. 
Naturally, you omit this parameter for any nonindexed file. 






n 
Is the number of the key being created. If omitted, 1 is assumed. You 
must start with 1 and continue sequentially through 5. Specify all the 
keys, each in its own KEY_n parameter. 


size 
Is the number of character positions in the key being created. The 
maximum size is 80 characters per key. 


location 
Is the number of character positions into the record where the key begins. @ 





DUPLICATES permits identical values for different keys in the file. 
NO_DUPLICATES prohibits keys with identical values. 


CHANGE permits future file update programs to change the index. 
NO_CHANGE prohibits change. 


Example: 


You're creating a file on a remote system and you want to create a 2-key 
index. Each record in your file has the following fields: 


employee-name employee-number — social-security-number pay-class 





Number of 
characters: 50 8 9 2 
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@ You want to use employee-number as the first index key and pay-class as 
the second key. Therefore, in the DDP CREATE command, you first 
specify: 


athens : We want to allow change, but there 
The size is 8 since the employee-number 


field we’ S Chak oe won't be any duplicates in 
ield contains 8 character-positions f ainplovas-numbers 


—, 
KEY_1 =(8, 51 CHANGE) 


This is the first index ae | feces location is 51, since that’s the 


number of character-positions into the 
record where the employee-number field 
starts 


Following this plan, the other key you need to specify is: 


The number of character-positions 
: P Many employees have the same pay-class 
in pay-class { 


et 
KEY_2 =(2, 68 DUPLICATES CHANGE) 
~— —_—_—— 


The second key Pay-class changes when 
employees are promoted 


The first character-position of pay-class is 
located here 


@ cs ta | 


EVEN 


Is the parity system for tape files. Omit for disk and diskette files. If omitted 
and DEVICE_CLASS=TAPE, the default depends on the SYSGEN option 
selected at the receiving host. 





RECORD_FORM= 
VARIABLE 
UNDEFINED 
Specifies whether record length is fixed or variable. The default is FIXED. You 


may use the UNDEFINED specification only for copying tape files in which the 
length is immaterial. 


RECORD_SIZE={maximum-number -of-characters/1-5 oe 


Is the maximum number of characters in a record. Use this parameter only if 
FILE_TYPE=SEQUENTIAL, RELATIVE, or INDEXED. If DEVICE_CLASS= 
DISKETTE, your maximum record size is 256 characters. If omitted, a record 
size of 256 characters is assumed. 
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cadets 


Example: 


You 





Specifies that the file you create is either cataloged in the catalog file (specify 
CATALOG) or simply registered in the volume table of contents of the volume 
you're using (specify VTOC). If omitted, CATALOG is assumed. 


Registering the file only in the VTOC takes less time and therefore costs less 
than cataloging it. However, there are two disadvantages to registering it in the 
VTOC only. One is that every time you refer to the file, you have to specify 
the volume name as part of the file-id. The other is that you cannot perform an 
indirect copy to an uncataloged file. (For additional information on indirect 
copies, see the DDP COPY command format and parameters, MODE= 
parameter, 8.3.2.) 


want to create a cataloged file on host HOO1, disk volume VOLOO/7, that has 


read and write passwords, a block size of 182, and a record size of 91. Records 
are fixed. The file is smaller than three cylinders. You're planning to copy a file into 
the one you're creating, so you can use the FILE_TYPE default of UNDEFINED. The 
command is: 


number of 
read characters 
password volume in record 


| 


DDP CREATE FILE=H@01::',REM/PERS (AXS9/AXSA7) ,VOL@07' BLOCK_SIZE=182 RECORD_SIZE=91 
~~ eee” —— 


{ 


file name write number of 
password characters 
in block 


8.3.2. Copying Files or Modules (DDP COPY) 


Function 


and Requirements: 


With the DDP COPY command function, you can duplicate either an entire file or a 
module from a file on another system. Follow these requirements to ensure correct 
copying: 


You can copy only to a file that has already been established. Thus, you might 
first issue a DDP CREATE command to establish the file, then a DDP COPY 
command to fill it. However, you can copy to any file on a remote host to 
which you have access; the file doesn’t have to have been established through 
a DDP command. 


You must know the locations (host-ids) of all files you access. 


See Table 8-2 for the ways records are stored in files of various types. 
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See Tables 8-3 and 8-4 for the limitations on originating and destination files 
during a DDP COPY. 


The two files may be on the same or different hosts. For instance, you may 
copy from file X on host A to file Y on host A. Or you may copy from file X 
on host A to file Y on host B. 


You may copy from a remote file to another remote file. In other words, your 
local host doesn’t have to be either the originating or the destination host. 


The record form of the originating and destination files do not have to be the 
same. 


You may not use a DDP COPY command to alter the element-type of a 
module. Its element type remains the same in the destination file as it was in 
the originating file. 


You can use a DDP COPY command to alter a user-specified MIRAM library 
element type. 


= co nase 










ATO= te 


AELEMENT_TYPE=/§ 
RELOCATABLE 
ABSOLUTE 
MACRO 
PROC 

AKEY 





COMPILED_JOB 
SCREEN_FORMAT 


gees 
[i 
INDIRECT 
fae ( \ 
SOF 


we ASCII 
fee 
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Parameters: 





originating-host-id 
Is one to four alphanumeric characters naming the originating host. If omitted, 
DDP assumes the originating file is on your local host. For more information, 
see 7.1.2. 


originating-file-id 
Is 1 to 74 alphanumeric characters identifying the input file. For more 
information, see 8.2.1. 


If your originating file is a LIBRARY file, its element type must be the same as 
the element type of the destination file. 


NOTE: 


Table 8-3 shows restrictions on the DDP COPY command for some types of 
originating files. 


destination-host- id 
Is one to four alphanumeric characters naming the host to receive the data. If 
omitted, DDP assumes the destination file is on your local host. For more 
information, see 7.1.2. 





destination-file-id 
Is 1 to 74 alphanumeric characters identifying your file. For more information, 
see 8.2.1. 


If the destination file is a LIBRARY file, its element type must be the same as 
the element type of the originating file. 


NOTE: 


Table 8-4 shows some restrictions on the DDP COPY command for various 
types of destination files. 


ELEMENT_TYPE= 





RELOCATABLE 
ABSOLUTE 
MACRO 

PROC 
COMPILED_JOB 
SCREEN_FORMAT 


Is the element type of the module. Specify this only when you are copying a 
module from a library rather than the entire file. You may omit this parameter if 
your file-id contains the element type. If you decide to specify the element 
type using this parameter, you must use this special vocabulary for element 
types: 
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é& SYMBOLIC: source code 
RELOCATABLE: object code 
ABSOLUTE: an executable program (load code) 


MACRO: parts of assembler programs in which values may be substituted 
(macros) 


PROC: parts of programs in any language in which values may be 
substituted (jproc or source format) 


COMPILED_JOB: compiled job streams with expanded jprocs 
SCREEN_FORMAT: screen formats 


The reason DDP uses this vocabulary is that we've designed it eventually to link OS/3 
with other systems. 


In library files, the element types of the originating and destination files must match. 


If this parameter is omitted, SYMBOLIC is assumed. 


@ KEY RA eka — 
| eee | 


Is used to change an index for the file on the receiving host. You need one of 
these parameters for each index key in the record (to a maximum of five), even 
if you change only one. Naturally, you omit this parameter for any nonindexed 






file. 

n 
Is the number of the key being changed. If omitted, 1 is assumed. You 
must start with 1 and continue sequentially through 5. Specify all the 
keys, each in its own KEY_n parameter, even though you may be 
changing only one of them. 

size 


Is the number of character positions in the key being changed. The 
maximum size is 80 characters per key. 
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location 
Is the number of character positions into the record where the key begins. 


DUPLICATES permits identical values for different keys in the file. 
NO_DUPLICATES prohibits keys with identical values. 


CHANGE permits future file update programs to change the index. 
NO_CHANGE prohibits change. 


Example: 


You're copying a nonindexed file to a remote system and you want to 
create a 2-key index. Each record in your file has the following fields: 


employee-name employee-number — social-security-number pay-class 


Number of 
characters: 50 8 9 2 


You want to use employee-number as the first index key and pay-class as 
the second key. Therefore, in the CHANGE command, you first specify: 


The size is 8 si th ; Saini We want to allow change, but there 
fi aoe oF ee bia ad ra alle a won't be any duplicates in 
ield contains 8 character-positions employee numbers 

en, 


KEY_1 =(8, 51 CHANGE) 


This is the first index | qe, location is 51, since that’s the 


number of character-positions into the 
record where the employee-number field 
starts 


Following this same plan, the other key you need to specify is: 


The number of character- ea 


y Many employees have the same pay-class 
in pay-class Pak, . abias pare 


KEY ai =(2, 68 DUPLICATES CHANGE) 


——— 


Pay-class changes when 

acl tL 

Mnersecond. key employees are promoted 
The first character-position of pay-class is 


located here 


MODE= 





WAIT 


INDIRECT 
MODE=DIRECT means that the device or medium needed to copy the file at 
the destination host must be immediately available. If not, the command 
aborts. DIRECT is the default. 
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MODE=WAIT means that either the destination file or the originating file is not 
immediately available, the system should hold the command until both the 
originating and destination file are free and then execute the DDP COPY. In this 
case, of course, the COMMAND COMPLETED message won't appear until the 
devices have been freed and the copy performed. Note, however, that each 
host has a time limit for which it will hold any command. If this time limit 
elapses and the devices are still not free, DDP aborts your command. 


MODE=INDIRECT permits the facility to build a temporary file at the 
destination host, if necessary, to store the file copy for later automatic transfer 
to the proper device. If it is possible to perform a DIRECT copy, however, the 
system will do so. You may not specify INDIRECT unless your destination file 
is cataloged. MODE=INDIRECT is only available for SAT or MIRAM library files. 


peas, 4 
SOF 


Specifies overwriting or extending of the destination file. POSITION=EOF (end 
of file) means that a copy of the originating file is appended to the end of the 
destination file. POSITION=SOF (start of file) means a copy of the originating 
file overwrites the destination file, and all previous contents of the destination 
file are lost. The default is EOF. 





If you specify EOF, then: 
m The destination file can't be an UNDEFINED file that’s empty. 


m= The block and record sizes of the originating and destination files must 
match. 


@ Record storage is as shown in Table 8-2. 


Table 8-2. How Files Store Additional Records at the End of File 


If the destination Then records are added to 

file is this type: the destination file: 

INDEXED by record key 

LIBRARY with new modules overwriting those with the same name and additional 
modules added to the end of the file 

SEQUENTIAL in the order transferred, following the last record of the destination file. 


If you specify SOF, the destination file may have any file type, because it’s 
completely overwritten with the originating file, whose type it adopts. 
RELATIVE files store records in successive relative record positions, beginning 
with the first. 












Tables 8-3 and 8-4 give additional information on the use of the POSITION 
parameter. 
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TRANSLATE= {ASCII 





NONE. 
Indicates the character code you want the file translated to as it arrives at the 
destination host. If omitted, EBCDIC is assumed. 


If you send a file to a host using a different encoding system but you do not 
want the file to be translated to the host’s encoding system, specify NONE. 
NONE means that the destination host holds the file in the original code. It can 
transfer the file but cannot access it to perform useful work. 


Table 8-3. DDP COPY Restrictions for Originating Files 


; If the And And you 
originating POSITION= also 
file type is: specify: 
INDEXED 


an INDEXED keys of both originating 
destination file and destination files 
must be identical 





module name destination file may be 
LIBRARY (with or without 
module name specified), 
SEQUENTIAL, or INDEXED 


destination file may be 


LIBRARY EO that the complete destination file must be 
library is to be LIBRARY and the TO= 
copied, or the parameter must not 
file-id contains contain a module name 
an element type 
but no module name 

EO 
EO 


LIBRARY, SEQUENTIAL, 
or INDEXED 


SEQUENTIAL 

or INDEXED 
the file is treated as a 
data file 


UNDEFINED either 
UNDEFINED either 

with nothing 

in it 


7 a 


F 

F 

F 

F 
i DDP COPY command 
is aborted 











UP-8811 Rev. 1 SPERRY UNIVAC OS/3 8-21 


DISTRIBUTED DATA PROCESSING 





@ Table 8-4. DDP COPY Restrictions for Destination Files 


If the 
destination 
file type is: 


INDEXED an INDEXED keys of both files must 
originating file be identical 


ee | 


And 
POSITION = 


either module name originating file must be 

LIBRARY 

LIBRARY either POSITION parameter is 
ignored. Modules from the 
originating file with the 
same name as destination- 
file modules overwrite 
those modules. Other 
modules are added to the 
end of the file. 


= ill 


module name and 
an originating 

file that is not 

a LIBRARY file 


the resulting module at 
the destination file is 
source (symbolic) 


UNDEFINED 
with nothing 





POSITION must be SOF. If 
i i POSITION=EOF, the command 
in it is aborted. 


Example: 


You want to copy file PERSNNEL into the blank cataloged file REM/PERS on host 


HOO 1, 


which uses EBCDIC. 


If a direct connection isn’t possible, you want the 


system to hold the command until it is. The command is: 


DDP COPY FROM= 


,PERSNNEL(JMS8/)' TO= HOO1: . 
——— 


read destination 
password file name 


en, 
,REM/PERS(/ASXA7)' MODE=WAIT 
——— 


t i‘? t 


originating host-id write 
file name password 
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8.3.3. Purging Files or Modules (DDP PURGE) 


Function and Requirements: 


The DDP PURGE command physically removes a file or module and all references to 
it from a host. Follow these instructions to ensure proper purging of your file: 


m= You may purge only existing files or modules. A DDP PURGE command for a 
nonexistent file results in an error. 


= if the file or module has passwords, you must know them to purge it. If the 
file has both read and write passwords, you must specify both to purge the 
file. 


m = If the file is cataloged, the DDP PURGE command will decatalog the file. 





Format: 
eee ee 
Parameters: 
host- id 
Is one to four alphanumeric characters naming the host you are purging the file 
or module from. If omitted, DDP assumes the file is on your local system. For 
more information, see 7.1.2. 
file-id 
Is 1 to 74 alphanumeric characters identifying the file to be purged. For more 
information, see 8.2.1. 
Example: 


You want to purge cataloged file REM/PERS on host HOO1. The command is: 


read 
host-id password 


{ 


DDP PURGE FILE=H@@1::' ,REM/PERS(AXS9/AXSA7)'! 
en ee? — 


t { 


file name write 
password 
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8.4. REMOTE JOB COMMANDS: DDP SUBMIT FILE, DDP CANCEL, AND 


DDP SUBMIT REQUEST 


There are three DDP job commands: DDP SUBMIT FILE, DDP CANCEL, and DDP 
SUBMIT REQUEST. 


The DDP SUBMIT FILE command sends a file of job control streams to a host for 
execution. You also use it to initiate a file of job control streams already at the host 
or to bring a job control stream to your local host for execution. 


The DDP CANCEL command terminates a job that you've submitted. 


The DDP SUBMIT REQUEST command sends an operator command to a remote 
host. 


8.4.1. Submitting Files and Modules for Execution (DDP SUBMIT FILE) 


Function and Requirements: 


The DDP SUBMIT FILE command sends a file of job control streams to a host for 
execution. You also use it to initiate a file of job control streams already at the host 
or to bring a job control stream to your local host for execution. The receiving host 
returns the output to you, sends it to another host, or retains it. 


Follow these instructions to ensure proper functioning of the DDP SUBMIT FILE 
command: 


= The module or file you submit must contain complete job control streams. 


m™ You may submit only SYMBOLIC (source code) or COMPILED_JOB (compiled 
jobs with expanded jprocs) files and modules. 


m Output can be routed to any host in the network, but there must be a direct 
connection from the host on which the jobs were executed and the host to 
where the output is directed. 


= The destination host must have all the resources required by your job control 
stream. 


m= The job stream file may be anywhere in your DDP network. It does not have to 
be at the destination host or at your local host. Specify its location in the 
FILE= parameter. The DDP SUBMIT FILE command sends the file of job 
control streams to the receiving host. 
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Format: 









pac locas (a inating-host- i hide id 
grea aie } 
COMPILED_JOB 


ee | 


Parameters: 


originating-host- id 
Is one to four alphanumeric characters naming the job control stream file 
location. If omitted, the system assumes the file is on your local system. For 
more information, see 7.1.2. 


file-id 
Is 1 to 74 alphanumeric characters identifying the input file. For more 
information, see 8.2.1. 


The file-id in the DDP SUBMIT FILE command may be either a sequential data 
file, which has no module name, or a module in a library file, in which case the 
module name must be present. (Normally you won't be submitting your entire 
library for execution.) In either case, the sequential file or the module may 
contain more than one job name. The destination host runs all jobs submitted 
in this file or module. 





PEMeNTTvE } 
COMPILED_JOB 


Is the element (module) type of the submitted file. SYMBOLIC indicates source 
code. COMPILED_JOB indicates compiled job streams with expanded jprocs. 
You may omit this parameter if the element type is SYMBOLIC (the default), or 
if the element type is specified in the file name. Normally, you won't be using 
COMPILED_JOB. 


HOST=f{destination-host-id 





Is one to four alphanumeric characters naming the host you submit the file to. 
If omitted, the command assumes the file is to be submitted to your local 
system. For more information, see 7.1.2. 
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NOTE: 
DDP renames jobs with the format xxxxyyyy 
where: 


XXXX 
Is the node that initiated the DDP SUBMIT FILE command. 


yyyy 
Is a unique 4-digit number. 


Example: 


You want to submit a job to remote host HOO1. You've already stored the job at 
your local host in module PAYO6 of library file PAYJOBS. The command is: 


module read destination 
name password host-id 


| 


DDP SUBMIT FILE='PAY@6,PAYJOBS (JMS17/),,S' HOST=H0O1 
ee” 


t 


file name element 
type 


Alternate forms of this command are: 


DDP SUBMIT FILE='PAY@6,PAYJOBS(JMS17/)' ELEMENT_TYPE=SYMBOLIC. HOST=H0O1 
DDP SUBMIT FILE='PAY@6,PAYJOBS(JMS17/)' HOST=HOO1 


Response Messages: 


As explained in 8.2.6.3. when DDP accepts your DDP SUBMIT FILE command, it 
returns a job name to you as part of the message: 


DDP@44 JNR 044 jobname JOB SUBMITTED FOR WO=nnnnnn time 


For example: 


DDP@44 JNR 044 AAAAGOO1 JOB SUBMITTED FOR WO=0900012 13:47:56 


Write down the job name and its work order number. (You may want to use the 
log sheet in Appendix G to do this.) You need your job name to cancel the job or 
to inquire as to its status. 
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8.4.2. Cancelling a Job or Command (DDP CANCEL) 





Function and Requirements: 
The DDP CANCEL command terminates an executing or backlogged job or a 
command executing on a host. Follow these instructions to ensure proper 
cancellation of your job or command: 


m You must specify the host on which you are running the job or command 
unless it is your own local host. 


m You may cancel only jobs or commands you have submitted under your 


















user-id. 
Format: 
DDPACANCELAJOB= [= -id \ eo 
pe \ 
ee alee res 
Parameters: 

host- id 
Is one to four alphanumeric characters naming the host that the job is 
executing on. If the host-id is omitted, the system assumes the job is 
executing on your local system. For more information, see 7.1.2. 

jobname 
Is eight alphanumeric characters naming the job that the system returns to you 
on the successful completion of your DDP SUBMIT command. (See 8.2.6.3 
and 8.5.1 for more information on the jobname parameter.) 

cia ' 

D 

Specifies what you want done with the spooled output from the job you 
cancel. DISCARD is the default and means the system erases the spooled, 
completed output files. DISCARD does not apply to job output files in process. 
DELIVER means that the spooled output files go to the host that would have 
received the completed output. 

COMMAND= 





he command that you entered but now wish to cancel. 
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work-order -number 
Is the one to six alphanumeric work-order-number that was displayed to you 
when command was accepted. 


Example: 


You want to cancel job AAAAOO0O1 on host HOO1 because there’s an error in the 
program. If there’s any output, you want it sent to you, since that might help you 
diagnose the problem. The command is: 


destination 
host-id 


ere, 
DDP CANCEL. JOB=H@01::AAAA0@01 OUTPUT=DELIVER 
——— 


t 


job name returned 
by DDP 


8.4.3. Submitting a Statement for Execution (DDP SUBMIT REQUEST) 
Function and Requirements: 


The DDP SUBMIT REQUEST command lets you send a statement to a remote host. 
The statement is an instruction for the remote host to perform some task, such as 
an operator command to run a utility program. Like anything else you submit to a 
remote host, it must conform to the configuration of the remote host. 


When you use DDP SUBMIT REQUEST, DDP doesn’t check the contents of the 
statement at all. You are responsible for sending a correct, executable statement to 
the remote host. Also, DDP can’t inform you whether or not your statement was 
executed at the remote host. If, for instance, you send a request to prep a disk, 
DDP can tell you that your statement was delivered successfully; but it can’t tell 
you if the disk was actually prepped. However, you do receive any messages 
generated by the command submitted. 


Format: 





DDPASUBMITAREQUEST=statement eae i 
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Parameters: 





statement 
Is the system command or message being submitted. The statement must be 
enclosed in apostrophes (’) if it contains any of the following: comma (,), space 
(A), semicolon (;), exclamation mark (!), apostrophe (’), quote (‘’), pound sign 
(#), equal sign (=), or ampersand (&). In addition, you must double any 
apostrophes within statements enclosed in apostrophes. 


Most statements you'll be sending will be character strings. 


host-id 
Is one to four alphanumeric characters naming the destination host. If you omit 
this parameter, DDP submits the request to your local host. For more 
information, see 7.1.2. 


Example: 


The purpose of the DDP SUBMIT REQUEST command is to save you time when 
you want to do routine tasks on the remote host. Let’s say, for instance, that 
you're just starting out in your connection with a remote host, whose host-id is 
N852. You're going to be sending a large number of files to that host, so you need 
your own disk. The remote host has an 8430 disk that they’ve already prepped, 
using the volume serial number VSN999Q. Since this will be your disk, you want to 
put your own serial number on it, 186309. 





One way to change the serial number would be to establish a file on your local 
host, put the job control stream to change the number into it, then enter the DDP 
SUBMIT FILE command. But that’s three steps. A much easier way would be to 
use the DDP SUBMIT REQUEST command with the canned job control stream that 
Sperry Univac supplies to change volume numbers. All you'd have to do is enter: 


new 
name of the canned serial destination 
job control stream number host-id 


‘ ~_ —_— pa 
DDP SUBMIT. REQUEST='RU CGV, ,O=VSN999 ,N=186309,T=30' HOST=N852 


t t 


old serial type of 
number disk (8430) 


The number is changed for you. 
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NOTES: 


1. You can get more information about using the RU CGV command to change a 
volume serial number by consulting the Series 90 system service programs 
(SSP) user guide, UP-8062 (current version) or the System 80 system service 
programs (SSP) user guide, UP-8841 (current version). 


2. You cannot specify the following commands with the DDP SUBMIT REQUEST 
command: DISPLAY, DELETE, BREAKPOINT, FILE, IN, SU, TU, and PD. An 
error message is displayed if any of these commands are sent. 


8.5. INFORMATION COMMANDS: DDP STATUS AND DDP TALK 


There are two DDP commands that send information back and forth between hosts 
without involving jobs or files. They are: 


m DDP STATUS, which tells you about a remote host, file, or user, or about a 
command or job you've sent; and 


= DDP TALK, which allows you to send a message to a remote user or operator. 


8.5.1. Finding Out the Status of a DDP Command, Host, User, File or Job 
(DDP STATUS) 


Function and Requirements: 


You can find out the status of a command you entered, a host in your system, a 
user, a file, or a job, by using the DDP STATUS command. You might want to use 
this command, for instance, to see if a file your job needs is currently available or 
to see if a job you've submitted to a remote host via the DDP SUBMIT REQUEST 
command has executed successfully. 


This command provides statistics only for those commands that you entered for 
that host. Do not use this command as the object of another DDP STATUS 
command. For systems with main storage capacity of 512 KB, DDP should be used 
in a dedicated system environment and commands should only be_ issued 
sequentially (a command must be processed before another can be issued). 
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Format: 





DDPASTATUSA{ COMMAND=work - order - number 
HOST=host- id 


a [an pieriene 


as Hse i eee ncaa parameter ] 


ice 














Parameters: 


COMMAND=work - order -number 


Displays the status of a command you entered. For types of information 
provided, see 8.5.1.1.1. 


work - order -number 
Is the one to six alphanumeric work-order-number that is displayed to you 
when your command is accepted. Note and use this number when enquiring 
about a command you have issued. For more information, see 8.2.6.2. 


HOST=host- id 
Informs you whether users on a host are active or not. For the types of 
information provided, see 8.5.1.1.2. 





host-id 
Is one to four alphanumeric characters naming the host whose status you 
want. If you do not specify host-id, the local host is assumed. For more 
information, see 7.1.2. 


“t 


Tells you the status of a job such as COMPLETED, BEING PROCESSED, or IN 
SCHEDULER. 








t-id apres 


host-id 
Is one to four alphanumeric characters naming the host where the job was 
sent. DDP assumes the job is on the local host if the host-id is not specified. 
For more information, see 7.1.2. 


jobname 
Is one to eight alphanumeric characters naming the job that the DDP SUBMIT 
FILE command returned to you. For more information, see 8.2.6.3. 
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& Local -host-id 
Is one to four alphanumeric characters naming the host you are using at your 
site. For more information, see 8.5.1.1.3. 


FILE= 





bal teen een parameter } 


Provides information on your data and library files. For the types of information 
provided, see 8.5.1.1.4. 


host-id 
Is one to four alphanumeric characters naming the host where the file resides. 
If you omit this name, DDP assumes the file is on your local host. For more 
information, see 7.1.2. 


file-id 
Is 1 to 74 alphanumeric characters identifying your file. This file-id can be a 
library file or data file. For more information see 8.2.1. 


keyword parameter 
Is the keyword parameter, if any, associated with your file. 


users [te st 


Lists a table of DDP functions for a particular user. 






id ie user-id 


If you're working from a system console, you may request the status of any 
user in the system. If you're working from a terminal or workstation, though, 
you may request only your own status. (That is, you may enter this command 
only with your own user-id.) 


host-id 
Is one to four alphanumeric characters naming the host where the user is 
located. If omitted, DDP assumes the user is on your local host. For more 
information see 7.1.2. 


user-id 
Is the one to six alphanumeric characters identifying the user. This is the 
same user-id a user would use in the LOGON command. 





8.5.1.1. DDP STATUS Command Information Summary 


The DDP STATUS command provides the following information at interactive services 
shut-down time for the parameters listed. 
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8.5.1.1.1. COMMAND= parameter 


This parameter displays: 


Originating (primary) host 
Destination (secondary) host 
Time the command was accepted 
Time the command was completed 
Status information such as: 

BEING PROCESSED 

IN SCHEDULER 


COMPLETED 


Example: Response to DDP STATUS COMMAND: 


W.O. # FUNCTION PRIM SECN STARTED COMPLETE STATUS 


where: 

W.0. # 
is the work order number of the command whose status you're requesting. For 
additional information about work order numbers, see 8.2.6.2. 

FUNCTION 
ls the name of the command whose status you're requesting, such as DDP 
COPY or DDP PURGE. 

PRIM 
Is the host-id of the primary host involved with a command. If the command 
involves an originating file, the primary host is the host that has that file. 
Otherwise, the primary host is the host originating this command. 

SECN 
Is this host-id of the secondary host involved with a command. If the 
command involves an originating file, the secondary host is the destination 
host of that file. Otherwise, the secondary host is the destination host for this 
command. 

STARTED 


Is the time a command was sent. 
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COMPLETE 
Is the time a command was completed, if it was. 


STATUS 
Specifies status information. 


Log printout sample: 
DDP STATUS COMMAND=5 
@B DDPO@2 CA1 @62 STATUS COMMAND ACCEPTED WO=000024 12:23:35 
OC W.C.# FUNCTION PRIM SECN STARTED COMPLETE STATUS 
@D 000005 COPY NOD4 NOD2 12:09:14 12:09:32 BEING PROCESSED 
@E DDP@22 FTR @22 STATUS COMMAND COMPLETED WO=000024 12:23:42 
BR CN 

8.5.1.1.2. HOST= parameter 

This parameter displays: 

m= =Number of local DDP users 

m= Number of remote DDP users 


= Number of buffers in use by DDP to service the users 


= Total number of bytes of memory used by the buffers identified in the preceding 
item. 


Example: Response to DDP STATUS HOST: 


USERS LOCAL REMOTE BUFFERS BUF SIZE W. OQ. COUNT 


USERID HOST STATUS 


where: 


USERS 
Is the total number of users on the DDP network. 


LOCAL 
Is the number of local users on the DDP network. 


REMOTE 
Is the number of remote users on the DDP network. 
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BUFFERS 
Is the number of buffers being used. 





BUF SIZE 
Is the size of the buffers used. 


W. O. COUNT 
Is the number of active work orders being processed for this user. 


USERID 
Lists the user-ids of all valid DDP users on the host. 


HOST 
Is the host-id of the host issuing the STATUS command. 


STATUS 
Is either ACTIVE or INACTIVE. 


Log printout sample: 


DDP STATUS HOST=NOD2 

OK DDPO@O2 CA1 02 STATUS COMMAND ACCEPTED WO=000027 12:25:51 
@L USERS LOCAL REMOTE BUFFERS BUF SIZ W.0. COUNT 

OM 00005 00002 00003 00010 0048184 000003 

OP USERID HOST STATUS 

0Q SYSCON NOD2 ACTIVE 

@A SYSCON NOD4 ACTIVE 

@B DDP@22 FTR 622 STATUS COMMAND COMPLETED WO=@00027 12:25:55 








8.5.1.1.3. JOB= parameter 
This parameter displays: 

= Command work-order-number 
= Jobname 


= Job state: whether active, backlogged, rolled-out, terminated normally or 
abnormally 


m Seconds of CPU time used by the job 


= Amount of main storage used by the job 


= Number of pages, cards of output generated 
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© Example: Response to DDP STATUS JOB: 


JOB= PRI=__STEP=___PROG= SIZE= 


CPU TIME=__:_:_: PAGES= CARDS= 


CURRENT JOB CONDITION= 


where: 


JOB= 
Is the name of the job you're asking the status of. 


PRI= 
Is the current priority of the job. 


STEP= 
Is the current job step number. 


PROG= 
Is the program currently being executed. 


SIZE= 
Is the memory being used by the job. 


CPU TIME= 
Is the amount of CPU time used by the job. 


PAGES= 
Is the number of pages of spooled output produced by the job. 


CARDS= 
Is the number of punched cards produced by the job. 


CURRENT JOB CONDITION= 
Is the state of the job at this moment. 


Log printout sample: 


DDP STATUS JOB=NOD20003 

@B DDPOO2 CA1 902 STATUS COMMAND ACCEPTED WO=900022 12:20:32 
OC JOB=NOD200603 PRI=05 STEP=001 PROG=SMPLMU@® SIZE=0035840 
@D CPU TIME= 00:00:12.965 PAGES= 000000 CARDS= 900000 

®E CURRENT JOB CONDITION = WAITING FOR 1/0 

@F DDP@22 FTIR @22 STATUS COMMAND COMPLETED WO=000022 12:20:44 
BR CN 
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8.5.1.1.4. FILE= parameter 





This parameter displays: 
a Filename 

m File type 

m Number of extents 
# Number of cylinders 
= Number of tracks 

ws Block size 

= Creation date 

w Expiration date 


The file-id parameter and security read and write keys must be expressable as part of 
file-id for each system. 


The volume name must also be expressable as part of the file-id for files registered in 
the volume table of contents (VTOC). 





If the file-id contains any of the following characters embedded, then it must be 
expressed as a quoted string by enclosing it in apostrophes: 


ampersand exclamation mark 
apostrophe number (#) 
comma semicolon 

equals (=) space 


Each single occurrence of an apostrophe within the file-id must be replaced by two 
apostrophes, for example: 


JOE’S FILE would be expressed as: 


'JOE''S FILE' 




















UP-8811 Rev. 1 SPERRY UNIVAC OS/3 8-37 
DISTRIBUTED DATA PROCESSING 


Example: Response to DDP STATUS FILE: 


ch 0 =a ees Ore Oe Ce, OR EXT=___ 

VSN=__ CYL=____TRK=__TYPE=__ BKSZ=___ 

RCSZ=).- CRE-DATE=__/__/__EXP-DATE=__/__/__ 
where: 

FILE= 


Is the name of the file you're requesting status of. 


EXT= 
Is the number of extents occupied by the file. 


VSN= ‘ 
is the VSN from the file name string, if specified. 


CYL= 
Is the number of cylinders occupied by this file. 


TRK= 
Is the number of tracks (beyond whole cylinders), occupied by this file. 


BKSZ= 
Is the block size of the file. 


RCSZ= 
Is the record size of the file. 


CRE - DATE= 
Is the date the file was created. 


EXP -DATE= 
Is the expiration date of the file. 


NOTE: 


BKSZ, RCSZ, CRE-DATE, and EXP-DATE parameters are only available for files that 
have been opened at least once for processing. A DDP CREATE command does not 
open the file, and requesting the status of a newly created file will not return all of the 
fields described previously. 
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Log printout sample: 





DDP STATUS FILE=',$Y$SCLOD,RES' 

@G DDPO@O2 CA1 002 STATUS COMMAND ACCEPTED WO=000025 12:24:32 
@J FILE= $Y$SCLOD EXT= 902 
@K VSN= RES CYL= 9015 TRK= @@ TYPE= SAT BKSZ= 90256 

OL RCSZ= 06256 CRE-DATE= 82/05/14 EXP-DATE= 99/12/31 

DM DDP@@2 FTR @22 STATUS COMMAND COMPLETED W0O=000025 12:24:42 


8.5.1.1.5. USER= parameter 

This parameter displays: 

= =§=©6The DDP functions performed for a particular user 

m Uncompleted and completed commands 

m Status of any user in your system (if issued from a system console) 
= Your own status only (if issued from a workstation or terminal) 


Example: Response to DDP STATUS USER 


USERID BUFFERS BUF SIZE W. O. COUNT 


W.O. # FUNCTION PRIM SECN STARTED COMPLETE STATUS 





where: 
USERID : 
Is the user-id of the user whose status you're requesting. | 
BUFFERS 
Is the number of buffers the user is using. 
BUF SIZE 
is the total buffer space the user is using. 
W. O. COUNT 
Is the number of active work orders being processed for this user. 
W. O. # 





Is the work order number of the command whose status you're requesting. For 
additional information about work order numbers, see 8.2.6.2. 
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FUNCTION 


Is the name of the command whose status you're requesting, such as DDP, 
COPY, or PAUSE. 


PRIM 
Is the host-id of the primary host involved with a command. If the command 
involves an originating file, the primary host is the host that has that file. 
Otherwise, the primary host is the host originating this command. 


SECN 
Is the host-id of the secondary host involved with a command. If the command 
involves an originating file, the secondary host is the destination host of that 
file. Otherwise, the secondary host is the destination host for this command. 


STARTED 
Is the time a command was sent. 


COMPLETE 
Is the time a command was completed, if it was. 


STATUS 
Specifies status information. 


Log printout sample: 


DDP STATUS USER=OPERATOR 

@Q DDP@62 CA1 002 STATUS COMMAND ACCEPTED WO=000026 12:25:10 
@A USERID BUFFERS BUF SIZ W.O. COUNT 

@B $YS$CON 00004 0018352 000000 

OC W.C.# FUNCTION PRIM SECN STARTED COMPLETE STATUS 

@D 000001 PURGE NOD2 NOD2 12:05:28 12:05:47 TERM NORMALLY 
@E 0006002 PURGE NOD2 NOD2 12:05:28 12:05:44 TERM NORMALLY 
OF 000003 CREATE NOD2 NOD2 12:06:16 12:06:18 TERM NORMALLY 


OG 000004 COPY NOD4 NOD2 12:07:41 12:07:47 TERM ABNORMALLY 
@J 000005 COPY NOD4 NOD2 12:09:14 12:09:32 BEING PROCESSED 
OK 000009 COPY NOD4 NOD2 12:13:36 12:13:56 BEING PROCESSED 


OL 600013 SUBMIT NOD2 NOD4 12:15:34 12:16:05 TERM NORMALLY 
OM 000015 TALKX NOD4 NOD2 12:16:28 12:16:47 TERM NORMALLY 
@P 000017 TALKX NOD4 NOD2 12:17:04 12:17:07 TERM NORMALLY 
@Q 000018 SPOOL NOD2 NOD4 12:17:05 ar IN PROGRESS 
OA 000021 SUBMIT NOD2 NOD2 12:19:15 12:19:37 TERM NORMALLY 
@B 900022 STATUS NOD2 NOD2 12:20:34 12:20:44 TERM NORMALLY 
@C 000023 STATUS NOD2 NOD2 12:21:38 12:21:46 TERM NORMALLY 
@D 900024 STATUS NOD2 NOD2 12:23:37 12:23:42 TERM NORMALLY 
@E 000025 STATUS NOD2 NOD2 12:24:33 12:24:42 TERM NORMALLY 
@F 000026 PURGE NOD2 NOD2 12:25:11 : IN PROGRESS 
@G DDP@22 FTR @22 STATUS COMMAND COMPLETED WO=000026 12:25:22 
BR CN 
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8.5.2. Communicating with a Remote Operator or User (DDP TALK) 





Function and Requirements: 
The DDP TALK command lets you send a message to a remote operator or user. 
You might want to have the remote operator mount your disk pack, for instance. 
Or, you might need to ask a remote user if he has recently updated a file you need. 


If the recipient of the DDP TALK message isn’t logged on, DDP displays the 
message at the system console. 


Format: 





DDPATALKAMESSAGE=' str ing'AUSER= [= -id |: j at a it] 


user-id 





Parameters: 


string 
Is the character string message you want the operator or user to get. 


host-id 
Is one to four alphanumeric characters naming the host where the operator or 
user is. If you omit the host-id, DDP assumes the user is on your local host. 
For more information, see 7.1.2. 





OPERATOR 
Is the operator of the remote host. 


user-id 
Is one to six alphanumeric characters identifying the user to the system. This is 
the same id as used in the LOGON command. 


WAIT 
Informs the operator or user that you want a reply. You do not have to wait 
for this reply to go on with other commands. Your keyboard isn’t locked 
during this period. 


Example: 


You want the operator on host HOO1 to mount your volume (VOLOO7). The 
command is: 


host-id 
where recipient 
message is located 


DDP TALK MESSAGE='PLEASE MOUNT VOL997' USER=HO01: :OPERATOR 
ee ee” 


{ 


recipient 
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8.6. HELP SCREENS FOR DDP COMMANDS 


Help screens are available for all of the DDP commands. To obtain information about 
available DDP commands and further help: 


1. Type: HELP DDP 


the following information will be displayed: 


DDP Commands Help Screen Requests 
DDP CANCEL HELP DDPCAN 
DDP COPY HELP DDPCOP 
DDP CREATE HELP DDPCRE 
DDP PURGE HELP DDPPUR 
DDP STATUS HELP DDPSTA 
DDP SUBMIT FILE HELP DDPFSB 
DDP SUBMIT REQUEST HELP DDPRSB 
DDP TALK HELP DDPTAL 
Parameters for CREATE HELP DDPPAR 


2. Enter the appropriate help screen request format shown in the aforementioned step 
1. 


3. Enter HELP DDPPAR if you need help with the parameters for the DDP CREATE 
COMMAND. 


NOTE: 


If you attempt to enter DDP through the System Menu, you will be told to enter HELP 
DDP for information about DDP. 
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9. The DDP File Access Facility 


9.1. INTRODUCTION 
This section describes how to: 
™ access and process files residing on remote OS/3 systems; and 


= write application programs that can initiate and communicate with one another to 
exchange data and control information. 


Both of these capabilities are provided as part of the DDP file access facility. 


9.2. REMOTE FILE PROCESSING 


Your programs can now access and process remote disk data (not library) files by 
simply adding a HOST=host-id parameter on the // DVC job control statement 
associated with a remotely located disk file. For example, if the disk file declared in the 
following control stream: 


// JOB MYJOB 


// DVC 50 

// VOL DOOO28 
// LBL INVFILE 
// LFD INPUTA 
// EXEC PROGA 


was located at a remote site, all that would be required to indicate that the file is at a 
remote site is the addition of the host-id parameter; as shown in the following: 
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// JOB 


// DVC 50,HOST=REM2 
// NOL 100028 

// LBL INVFILE 

// LED INPUTA 

// €XEC PROGA 

/& 


No program changes or additions are needed to process a remote file. 


9.2.1. Cataloging Remote Files 


Remotely accessed files can be cataloged as described in the file cataloging concepts 
and facilities manual, UP-8860 (current version). Further, they can be cataloged at 
multiple hosts. The host where the file resides would catalog it like any other file 
(excluding the HOST= parameter) while other hosts would include the HOST= 
parameter in its file description. 


9.2.2. Sharing Remote Files 


Remotely accessed files can be declared as sharable read files but cannot be shared for 
updating purposes (read/write files). 


9.2.3. Tradeoffs Involved when Processing Remote Files 


Figure 9-1 shows an application where the ability to access and process data at remote 
hosts has distinct advantages. As shown, the inventory display program is connected 
with three inventory files: one local and two remote. When information is needed about 
a particular product, the workstation user need only enter a display request. 


The inventory display program running at site A opens the applicable files and displays 
the requested information. The workstation user is unconcerned about where the 
requested information is stored. 


Such an application assumes that the inventory files maintained at the remote hosts are 
dynamic files that are constantly being updated, processed, and maintained by the 
remote hosts. Consequently, it would be inefficient to make copies of these files on 
host A each time host A wanted to access these files. 


ee Gh et Oh TEN lO Wet mx 
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Figure 9-71. Remote File Processing Application 


9.3. PROGRAM-TO-PROGRAM COMMUNICATIONS 


You can now write assembly language programs that can initiate and carry on a 
conversation with other assembly language programs at remote hosts. The 
communicating programs must reside on different hosts in a DDP network. 


9.3.1. Two Types of Programs: Primary and Surrogate 


There are two basic communication programs: primary and surrogate. The program that 
initiates a conversation is called the primary program and the initiated program is called 
the surrogate program. However, primary and surrogate programs can be designed to 
reverse roles if the application they are being used in so dictates. A primary program 
can call up to 255 surrogate programs. 


9.3.2. Two Types of Conversations: Simple and Complex 


There are two types of conversations that may be conducted between communicating 
programs: simple and complex. By definition, a simple conversation is one that takes 
place between only two programs and the primary/surrogate relationship between these 
two programs never changes. The primary program remains the primary program 
throughout the life of the conversation. There is a simple exchange of information. A 
primary program activates a surrogate program and provides it with data to be 
processed. The surrogate program performs the required processing. 
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A complex conversation is one that allows for the communicating programs to reverse 
primary/surrogate status, or that allows for more than two programs to be involved in 
the conversation. The procedures and guidelines for preparing communicating programs 
follow. 





9.4. PROGRAMMING CONSIDERATIONS FOR SIMPLE CONVERSATIONS 


9.4.1. Job Control Requirements 


Programs designed for use in a simple conversation application rely on job control to 
identify the location and name of the surrogate program. Simple conversation 
applications assume that the primary program will be initiated through the job control 
run process by a human operator and that the surrogate program will be initiated 
through the job control run process by the DDP facility. Consequently, both programs 
require an associated job control stream and both programs will occupy job slots in the 
system on which they are executing. 


The job control streams associated with communicating programs must contain a device 
assignment set for the program being addressed. For the primary program, this device 
assignment set must consist of a // DVC statement and a // LFD statement. The 
// DVC statement must be in the form: 





// DVC PROG, jobname,HOST=host- id 


where: 
PROG 
Associates the device assignment with the program-to-program component, 
rather than a conventional I/O device. 
jobname 
Identifies the name of the job you wish to communicate with. 
HOST=host- id 


Identifies the network name of the system on which the corresponding 
program is located. (This name is established when the communications 
network for your system is defined during system installation.) 

The // LFD statement must be in the format: 


// LFD filename 
where: 
filename 


Is the name specified for the FILENAME= parameter on the CDIB © 
macroinstruction issued by the primary program. 
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The surrogate device assignment set must also issue a // DVC statement and // LFD 
statement. However, the // DVC statement must have the following format: 


// DVC PROG 


where: 
PROG 
Associates the device assignment with the program-to-program software, 
rather than a conventional |/O device. 


The // LFD statement must be in the format: 


// LED filename 


where: 
filename 
Is the name specified for the FILENAME= parameter on the CDIB 
macroinstruction issued by the surrogate program. 
Example: 
Control Stream Control Stream 
To Run Primary To Run Surrogate 
Program Program 
at HOST AAAA at HOST BBBB 
// JOB PRIMJOB // JOB SURJOB 
// DVC PROG, SURJOB , HOST=BBBB // DVC PROB 
// LFD PRIMARY // LFD SURRGATE 
// EXEC PROGA // EXEC PROGB 
/& /& 
// FIN // FIN 


9.4.2. Coding Requirements 


To prepare BAL programs for use in simple conversation applications, you use a special 
set of consolidated data management macroinstructions to define, open and close, and 
transfer information between the communicating programs. These macroinstructions 
function the same way other data management macroinstructions do and, consequently, 
are designed to resemble them wherever possible. Two declarative and four imperative 
macroinstructions are used in this environment. 
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9.4.3. Declarative Macroinstructions 


Declarative macroinstructions are used to supply information concerning the files 
required by the issuing program. These macroinstructions generate nonexecutable code 
such as constants and storage areas for variables. The following two macroinstructions 
are used: CDIB and RIB. 


9.4.3.1. Defining a Common Data Interface Block (CDIB) 


The CDIB macroinstruction identifies the logical file required by the issuing program and 
establishes a common data interface block for the file. The CDIB is the function passing 
mechanism for the file and it is referenced each time you issue an imperative 
macroinstruction. 


Format: 

LABEL AOPERATIONA OPERAND 

name CDIB FILENAME=f ilename 
Parameters: 

name 


Specifies the name of the CDIB. This name cannot exceed seven characters. 


filename 
Specifies the filename that was assigned in the // LFD statement in the 
program execution job control stream for the issuing program. 


9.4.3.2. Defining a Resource Information Block (RIB) 
The RIB macroinstruction is used to describe the file characteristics required by the 
issuing program. The RIB is used in combination with the CDIB macroinstruction when 


you issue the DOPEN imperative macroinstruction to open the file. 


Format: 





LABEL AOPERATIONA 






OPERAND 
[HOSTID=host- id] 
[,PROGFD=symbol } 
{,RCSZ=n] 


, WKEM= (95 
VAR 


VARI 
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Parameters: 


HOSTID=host- id 
Specifies the 1- to 4-character alphanumeric name (first character must be 
alphabetic) of the host on which the destination program resides. This 
parameter is overridden by the HOST=host-id parameter of the // DVC PROG 
statement in a simple communications application environment. 


PROGFD=symbol 
Specifies the symbolic address of a data format descriptor list that you provide 
to indicate the type of data that is being transferred. This list has the following 
format: 


FORMAT FORMAT FORMAT 
pee See, 1 Pe dia eal 2 isis nickle n 


Notice that the data format descriptor list consists of a 2-byte header followed by one 
or more contiguous 2-byte data format descriptor entries. The 2-byte header contains 
the number of fist entries in binary. The first byte of the format descriptor entry 
contains a name that you define for a particular type of data. The second byte of the 
entry contains a hexadecimal value that specifies the particular type of data. The 
hexadecimal values and the type of data they specify are as follows: 





BYTE 


Hexadecimal Value Type of Data 

X80’ ASCII 

x'81' Compressed ASCII 
X'82' EBCDIC 

X'83' Compressed EBCDIC 
X'84' Katakana 

X'85' Compressed Katakana 
X'86' Transparent Octet 
X'88’ Kanji 


X'89' Compressed Kanji 
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This list is used when you transfer data. It is used with the DMINP and DMOUT 
operative macroinstructions (9.4.4.5, 9.4.4.4). If the PROGFD parameter is omitted, the 
data type is assumed to be transparent octet. 


RCSZ= 
Specifies the length, in bytes, of each record to be transferred. If RCSZ is 
omitted and WKFM=NO or WKFM=VAR is specified, the record length is 
assumed to be 256 bytes. 


WKFM= 


Specifies the format of the work area in which input and output records are 
placed. 


WK FM=NO 


Specifies that the work area format is the same as the record format. NO is 
the default. 


WK FM=VAR 
Specifies that the work area format is variable. For output operations, VAR 
must specify the amount of data in the first two bytes of the work area. For 
input operations, the maximum amount of data (determined by the RCSZ 
keyword parameter) is placed in the first two bytes of the work area. 


WKFM=VARI 
Specifies that the work area format is variable. For output operations, you 
must specify the amount of data in the first two bytes of the work area. For 
input operations, the first two bytes of the work area are automatically 
updated to reflect the amount of data. 


9.4.4. Imperative Macroinstructions 


The imperative macroinstructions are used to establish and close a communication path 
between user application programs, begin and end conversation between programs, 
transfer and receive data, and control the status of the programs. The instructions you 
use to cause these actions are: DOPEN, DCLOSE, DMOUT, and DMINP. 


9.4.4.1. Register Conventions 


When you use the imperative macroinstructions, the following registers must be used as 
indicated: 


Register @ 
The RIB address must be loaded in this register for the DOPEN 
macroinstruction. The workarea address must be loaded in this register for 
those macroinstructions that use workarea processing. 
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Register 1 
The CDIB must always be loaded in this register. 


if symbolic notation is used, the expansion of the imperative macroinstruction will load 
register O and/or register 1 with the appropriate address. All registers are returned 
unchanged when control is received back from an imperative macroinstruction. 


9.4.4.2. Status Checking 

Status checking is required after each imperative macroinstruction. This is necessary 
because control is always returned inline. A standard way of checking macroinstructions 
is described in the consolidated data management macroinstruction user guide, UP-8826 
(current version). 

9.4.4.3. Establishing a Communication Path (DOPEN) 

You use this macroinstruction to establish a communications path between user 
application programs. This instruction must be issued first by both the primary and 


surrogate application programs before any transfer of information is attempted. 


Format: 





LABEL AOPERATIONA OPERAND 


cdibname), {r ibname 
(1) (0) 
1 t) 
















Parameters: 


cdibname 


Is the symbolic name of the CDIB required by the program issuing the DOPEN. 


(1) or 1 
Indicates that you have preloaded register 1 with the address of the CDIB. 


ribname 
Is the symbolic name of the RIB required by the program issuing the DOPEN. 


(®) or 6 
Indicates that you have preloaded register O with the address of the RIB. 
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9.4.4.4. Outputting Data (DMOUT) 


The DMOUT macroinstruction is used to transfer (send) data from one application 
program to another. 


Format: 















OPERAND 


cdibname), {workarea 
(1) (@) 
1 () 


LABEL AOPERATIONA 





Parameters: 


cdibname 


Is the name of the CDIB required by the program issuing the DMOUT. 


(1) or 1 
Indicates that you have preloaded register 1 with the address of the CDIB. 


workarea 
Is the symbolic name of the work area that contains the record to be sent. 


(®) or @ @ 


Indicates that you have preloaded register O with the address of the work area. 





9.4.4.5. Receiving Data (DMINP) 
The receiving macroinstruction has the following format: 


Format: 








OPERAND 


cdibname }, {workarea 

(1) (0) 

1 @ 
cdibname 


Is the name of the CDIB required by the program issuing the DMINP. 


LABEL AOPERATIONA 













Parameters: 


(1) or 1 
Indicates that you have preloaded register 1 with the address of the CDIB. 
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eo workarea 


Is the symbolic name of the work area that contains the record to be sent. 


(®) or @ 
Indicates that you have preloaded register O with the address of the work area. 


if the PROGFD is specified in the RIB, you select the data format from the data format 
descriptor list by moving the 1-byte name you defined for the particular format into the 
CISFD field of the CDIB before you issue the DMOUT macroinstruction. If you do not 
move a name into the CDIB, the first data format in the list will be used. On a DMINP, 
the data name that comes across in the input buffer will be moved into the CI$FD field. 


9.4.4.6. Closing a Communications Path (DCLOSE) 


You use this macroinstruction to close a communications path between user application 





programs. 
Format: 

LABEL AOPERATIONA OPERAND 

name DCLOSE cdibname 

@ 
1 

Parameters: 

cdibname 


Is the symbolic name of the CDIB declared in the program issuing the DCLOSE. 


(1) or 1 : 
Indicates that you have preloaded register 1 with the address of the CDIB. 


9.4.5. Timing Considerations 


We recommend that the job streams for program-to-program communications contain 
no other job steps than those required for the execution of these programs. The reason 
for this recommendation is that only 10 minutes is allotted for starting a job; otherwise, 
a time-out will result. 
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9.4.6. Designing a Simple Conversation Program 


Simple conversation must contain the following three phases, which are also shown in 
the flow diagrams in Figure 9-2: 


m ~§= Initialization Phase 


Wherein the primary program initializes the conversation, via a DOPEN, with one 
and only one surrogate program, which also must issue a DOPEN. 


= Data Transfer Phase 


Wherein the primary program only transfers data to the surrogate program, after 
issuing DMOUTs and the surrogate receives data after issuing DMINPs. 


= #&Termination Phase 


Wherein the primary program and surrogate program must each issue a DCLOSE to 
terminate. 


The CDIBs and RIBs required by the DOPEN, DMOUT, DMINP, and DCLOSE 
macroinstructions are those of the program issuing the macroinstructions. Examples of 
simple conversation programs are given in 9.4.7 and a corresponding flow chart is 
shown in Figure 9-2. 





RECEIVED 
DEACTIVATE 
fe.os —— TERMINATION PHASE ——— fos) 
PRIMARY PROGRAM SURROGATE PROGRAM 


Figure 9-2. Simple Conversation Program Flow Diagrams 
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9.4.7. Examples of Simple Conversation Communications Programs 

The following are examples of simple conversation programs. 

9.4.7.1. Example 1: Simple Conversation Primary Program and Surrogate 
Program Pair 


Figure 9-3 and Figure 9-4 show the job control and coding, respectively for a very 
simple, complete primary program and surrogate program communicating pair. 


The following is the required job control: 


Primary Program Surrogate Program 
Job Control Stream 
// JOB PTPSPRIM // JOB PTSSURR 


// DVC PROG,PTPSSURR , HOST=BBBB // DVC PROG 


// LED filename field in the // LFD filename field in the 
primary CDIB surrogate CDIB 


// EXEC load module name // EXEC load module name 





Figure 9-3. Job Control for Example 1 
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The following is the coding for example 1: 


Primary Program Surrogate Program 


Line 


1 PRIMARY START @ SURROGATE START @ 


R1,PRIMCDIB R1,SURRCDIB 


R@,PRIMRIB R@,SRGATRIB 
(1), (0) (1), (0) 


R@, DATAMSG R@, IOAREA 
(1), (0) (1), (0) 


DCLOSE DCLOSE 


EOJ EOJ 
PRIMCOIB DC XL48'00' SURRCDIB_ DC XL48'@O! 
PRIMRIB RIB RCSZ=80 SURGATRIB RIB RCSZ=80 
DATAMSG OC CL80'oO'! IOAREA DC XL80'OO! 





Figure 9-4. Simple Conversation Primary Program and Surrogate Program Pair for Example 1 (Part 1 of 2) 

















UP-8811 Rev. 1 SPERRY UNIVAC OS/3 9-15 
DISTRIBUTED DATA PROCESSING 





ee Line Coding Description 





1 Each program starts its own program. 

2 The primary and surrogate programs each load their respective CDIBs and RIBs 
and into registers R1 and RO, respectively. 

3 

4 Both the primary and surrogate programs open their own CDIBs and RIBs. 

5 The primary program loads a data message into RO, and the surrogate program 


loads its |/O area into its RO. 


6 The primary program issues a DMOUT to send the message and the surrogate 
program issues a DMINP to receive the message. 


7 Both programs close their respective communication paths to each other. 


8 Each program ends its own program. 
Figure 9-4. Simple Conversation Primary Program and Surrogate Program Pair for Example 1 (Part 2 of 2) 
9.4.7.2. Example 2: Simple Conversation Primary Program Repeatedly 
Transferring Data to a Surrogate Program 


Figure 9-5 shows a primary program transferring 50 messages to a surrogate program 
(shown in Figure 9-6) during simple conversation. 


Job Control Stream Required 


// JOB PRIMJOB 


// DVC PROG, SURJOB, HOST=BBBB 


// LFD PRIMARY 


// EXEC PROGA 
/& 
// FIN 





Figure 9-5. Job Control and Coding for Primary Program for Example 2 (Part 1 of 2) 
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BAL Program for the Simple Conversation Primary Program PROGA 


Description 


PROGA START @ 
BALR R15,0 
USING *,R15 
4* LOADING THE CDIB 
5 R1,PRIMARY Load the address of the following CDIB into R1: 
PRIMARY CDIB FILENAME=PRIMARY 
OPEN A CONNECTION TO THE SURROGATE HOST BBBB 
RO,PRIMRIB Load the address of the following RIB into RO: 
PRIMRIB_ RIB 


1 
2 


(1), (0) Open a session path to the surrogate program 
Check for a successful open 
EXECUTE DATA TRANSFER LOOP 
Set up counter for Loop 
R®,DATAAREA RO= address of data area 
(1), (0) Loop is executed, sending data 


Z Check for a successful send 





. Loop through 40 times 
es CLOSE THE CONNECTION TO THE SURROGATE HOST 
DCLOSE (1) Close the session path 


Check for a sucessful close 





Figure 9-5. Job Control and Coding for Primary Program for Example 2 (Part 2 of 2) 
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& 9.4.7.3. Example 3: Simple Conversation Surrogate Program Repeatedly 
Receiving Data from a Primary Program 


Figure 9-6 shows a surrogate program receiving 50 messages from the primary 
program (shown in Figure 9—5) during simple conversation. 


Job Control Stream Required 


// JOB SURJOB 


// DVC PROG 


// LFD SURRGATE 


// EXEC PROGB 





Figure 9-6. Job Control and Coding for Surrogate Program for Example 3 (Part 1 of 2) 
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BAL Program for the Simple Conversation Surrogate Program PROGB 


Description 


PROGB START @ 
BALR R15, 
USING *,R15 
LOADING THE CDIB 
LA R1,SURRGATE Load the address of the following CDIB into R1: 
. SURRGATE CDIB FILENAME=SURRGATE 





. ATTACH TO THE PRIMARY PROGRAM 
LA RO,SURRIB Load the address of the following RIB into RO: 
SURRIB RIB 
(1), (0) Attach to the primary session 


Check for a successful attachment 


PREPARE TO RECEIVE DATA FROM THE PRIMARY PROGRAM 
R@, INPAREA Load the address of the input area into RO 
(1),() Get data from primary program 


Loop 
Receive data transfer 





Loop to get more input 
CHECK WHICH OF THE EXCEPTION FLAGS IS SET IN THE CDIB 
TERMINATE THE ATTACHMENT TO THE PRIMARY PROGRAM 
DCLOSE (1) Detach from the primary program 


Check for a successful detach 








Figure 9-6. Job Control and Coding for Surrogate Program for Example 3 (Part 2 of 2) 


9.5. PROGRAMMING CONSIDERATIONS FOR COMPLEX CONVERSATIONS 


A complex conversation enables both primary and surrogate programs to send and 
receive data and exchange status roles via a more controlled discipline. Additionally, a 
primary program can simultaneously communicate with several surrogate programs. 
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9.5.1. The Three Phases of Complex Conversation 
A complex conversation also contains three phases: 
= ~=Initialization Phase 


Wherein the primary program initializes a conversation with one or more surrogate 
programs and receives a reply from the surrogate program. 


ms Data/control Transfer Phase 
Wherein the primary and surrogate programs exchange data and/or control. 

= #8 Termination Phase 
Wherein the primary program indicates to the surrogate that a conversation is to be 
terminated. The surrogate program responds to the primary and ends the 
conversation. 

9.5.2. Operational Characteristics of Complex Conversation 


The following operational characteristics apply: 


1. A program written as a primary program cannot be started as a surrogate program. 
However, once the primary program has started, it can pass to a surrogate transfer 
phase. 


2. A program written as a surrogate program cannot be started as a primary program. 

3. A job started (and running) by a primary program, whether it is running as a 
primary or surrogate program, cannot be attached to by another job. That is, there 
is no way to start or connect to a job that is already running. 

9.5.3. Macroinstructions Used in Complex Conversation 

The same declarative and imperative macroinstructions used in simple conversation are 


required in complex conversation, except that the keyword USE=PROG is also required 
in the primary program and surrogate program RIB for complex conversation, as follows: 





Format: 
LABEL AOPERATIONA OPERAND 
ribname RIB USE=PROG 


other keyword parameters 


The same imperative macroinstructions used in simple conversation are also used in 
complex conversation, along with the following two imperative macroinstructions: 
DMSEL and DMCTL. 
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9.5.3.1. Selecting the Surrogate (DMSEL) 


The select imperative macroinstruction, DMSEL, is used to begin and end conversations 
between paired application programs. Only the primary program can issue a DMSEL, 
and, since the surrogate program must reply with a DMOUT, the primary must next 
issue a DMINP. The DMSEL format is as follows: 


Format: 


sala fo ae he tee. heres 
cdibname surrogate-prog DEACT 


Parameters: 


cdibname 
Is the name of the CDIB specified in the primary program. If (1) is specified, it 
is assumed that the address of the CDIB has been preloaded into register 1. 


PROG 
Identifies DMSEL as belonging to the program-to-progam facility. 
surrogate-prog 
Specifies the name of the surrogate with which a conversation is to be 
activated or deactivated. If (0) is specified, it is assumed that the address of 
the name of the surrogate program has been preloaded into register O. 


ACT 
Indicates a conversation with the surrogate program named is to be activated 
(opened). 

DEACT 
Indicates a conversation with the surrogate program named is to be 
deactivated (closed). 

DATA 


Indicates that the next macroinstruction issued will contain data to be passed 
with the DMSEL. 


9.5.3.2. Special Control (DMCTL) 


¢ 


The special control imperative macroinstruction can only be used: 


= ~=by the primary program to pass control to the surrogate program via the BEQueath 
parameter; or 


m by the surrogate program to reply to a DMSEL with DEACT, issued by the primary 
program. 
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@ The format for DMCTL is as follows: 


ss tae pee 
cdibname END 
Parameters: 

cdibname 


Is the name of the CDIB specified in the primary or surrogate program, 
depending on whether the BEQ or END parameters, respectively, are specified 
as described below. 


PROG 
Identifies DMCTL as belonging to the program-to-program component. 


Issued only by the primary program, indicating it is passing control to the 
surrogate program. Upon reception of the BEQueath, the surrogate program 
becomes the primary program and the primary program becomes the surrogate 
program. If a reply was required from the surrogate, it is sent before the 
BEQueath takes effect. 


END 
@ Issued only by the surrogate program, and only as a reply to a DMSEL with 
DEACT, issued by the primary program, to indicate the conversation is to be 
terminated. 


9.5.3.3. Closing a Conversation Path (DCLOSE) 


The DCLOSE imperative macroinstruction is issued to close a communications path 
between user application programs, as for simple conversations (9.4.4.6), with the 
following exception. If the primary program has not issued a DMSEL with DEACT, or 
the surrogate program received the same when the DCLOSE was issued or received, the 
conversation will be aborted. 





9.5.4. Capabilities of Complex Conversation 


Compared to simple conversation, there are many more ways you can design primary 
and surrogate programs using the aforementioned imperative macroinstructions. 


Various procedures have been designed using these macroinstructions that you can use 
to perform the three basic communications phases: 


™® conversation initiation phase; 
& m data and control transfer phase; and 


™ conversation termination phase. 
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Additionally, within these basic procedures, various smaller steps can be taken, or you 
can link the procedures to pass from primary data transfer state to surrogate transfer 
state and, then, go back to the primary transfer state. 


Figure 9-13 is a master flowchart showing details of the procedures in all possible 
combinations that you might employ in writing a program set. Horizontally, the left 
section of the diagram shows the possible flow of a program starting as a primary 
program. The right section of the diagram shows a similar flow for a program starting 
as a surrogate program. Vertically, the diagram shows the program flow, for both 
programs, starting with the conversation initialization phase at the top, then the data 
and control phase and, finally, the conversation termination phase at the bottom of the 
diagram. 


The required macroinstructions and parameters are shown in the large circles of the 
procedure links and the smaller circles define the state your program arrives at. For 
example, all small circles with a 1 within signify the program has arrived at the primary 
data/control transfer phase. The small circles containing 2 signify the program has 
arrived at the surrogate data/control transfer phase. 


When a program starting as primary reaches the @) state, it continues from the 
surrogate state @ . Similarly, when a program starting as a surrogate reaches the @) 
state, it continues from the primary diagram state a) . See steps 6A to 7A, 6C to 7C, 
and 5D to 6D for examples 4, 5, and 6, respectively, and refer to Figure 9-13. 


The small circles enclosing a 3 or 4 indicate the program can enter the primary 
conversation termination phase or surrogate conversation termination phase, 
respectively. 


The notes signifying the conditions required before being able to continue in the flow, 
such as ‘‘received data’’, ‘‘pass data’’, ‘received BEQueath’’ and so forth, indicate the 
protocol conditions required to issue the macroinstructions or conditions that follow the 
use of the macroinstruction. For further information, refer to the previously described 
macroinstruction specifications. 
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@ 9.5.5. Job Control Requirements 


The job control for complex conversation is very simple, as shown for the following pair 
of communicating programs. 


For the Primary Program For the Surrogate Program 
// JOB jobname // JOB jobname 
// EXEC local module name // EXEC local module name 
/& /& 
// FIN // FIN 
where: 
jobname 
& For the primary program, jobname is the job name specified for the primary 
program. 


For the surrogate program, jobname is the job name specified for the surrogate 
program. 


load module name 
For the primary program, load module name is the name of the load module 
specified for the primary program. 


For the surrogate program, load module name is the name of the load module 
specified for the surrogate program. 


9.5.6. Examples of Complex Conversation Programs 


The following are examples of complex conversation programs. All of the programs 
listed have been referenced on the complex conversation procedures flow diagrams 
chart (Figure 9-13), according to the coding line number listed at the left side of each 
program that follows. Thus, you can relate the examples to the flow diagrams and learn 
how and why the examples were coded as they are and what other procedures could 
be used, if your program required it. 











UP-8811 Rev. 1 SPERRY UNIVAC OS/3 9-24 
DISTRIBUTED DATA PROCESSING 


9.5.6.1. Example 4: Complex Conversation Primary Program and Surrogate 
Program Pair With BEQueath 


The primary program (on the left side of Figure 9-8) issues a DOPEN, selects the 
surrogate program via DMSEL ACTivate to exchange status via DMCTL BEQueath. After 
receiving acceptance from the surrogate program, the program becomes the new 
surrogate program and receives data from the new primary program. 


The surrogate program (on the right side of Figure 9-8) issues a DOPEN, replies to a 
message from the primary program, accepts the BEQueath, and, as the new primary 
program, sends data to the new surrogate program. The program then issues a DMSEL 
DEACTivate and, after receiving a reply, closes the conversation. 


The required job control is shown in Figure 9-7. 


Primary Program Surrogate Program 
Job Control Streams 
// JOB PTPSPRIM // JOB PTPS$SRGT 


// EXEC load module name // EXEC load module name 





Figure 9-7. Job Control for Example 4 


The following is the coding for example 4: 
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Surrogate Program 


SURROGATE 


START @ 


LA R1,PRIMCDIB R1,SURRCDIB 


LA R@,PRIMRIB R®,SRGATRIB 


DOPEN (1),(@) (1), (0) 


RO,=CL8'PTPSSRGT! 
(1),PROG,(®),ACT,DATA 
R@,ACTMSG 


© (1), (@) ,UNLOCK 


| LA R®, IOAREA 
DMINP (1),(@) 


R®, IOAREA 
(1), (0) 


R@,RPLYMSG 
(1), (0) 


DMCTL (1),PROG,BEQ 
LA R@, BEQMSG 
DMOUT (1),(0) 


R@, IOAREA 
(1), (0) 


LA R®@, IOAREA LA R®@,=CL8'PTPSPRIM! 
DMSEL (1),PROG,(@),DEACT 
DMINP (1),(@) LA R@, DEACTMSG 





Figure 9-8. Complex Conversation Primary Program and Surrogate Program Pair for Example 4 (Part 1 of 2) 
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Primary Program Surrogate Program 


8A DMCTL (1),PROG,END 6B DMOUT (1),(@),UNLOCK 


R®@,RPLMSG R@, IOAREA 
(1), (0) (1), (@) 


DCLOSE DCLOSE 


EOJ 

PRIMCDIB DC XL48'00' SURRCDIB XL48'90! 

PRIMRIB RIB USE=PROG, SRGATRIB USE=PROG, 
HOSTID=BBBB RCSZ=80 
RCSZ=80 RPLYMSG CL8@'REPLY' 

ACTMSG CL8@' ACTIVATE! DEACTMST CL80'DEACTIVATE' 

BEQMSG CL80'BEQUEATH' IOAREA XL80'90! 

RPLYMSG CL8O'REPLY' 

IOAREA XL80'@0' 





Figure 9-8. Complex Conversation Primary Program and Surrogate Program Pair for Example 4 (Part 2 of 2) 


9.5.6.2. Example 5: Complex Conversation Primary Program Issuing a 
BEQueath and Repeatedly Receiving Data Transfers 


Figure 9-9 shows the primary program issuing a DOPEN and DMSEL to select the 
surrogate program (shown in Figure 9-10) and passes control to it via a BEQueath. As 
the new surrogate program, it repeatedly receives data transfers from the new primary 
program, replying whenever necessary. 
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Job Control Stream Required 


// JOB PRIMJOB 


// EXEC load module name 


BAL Program for the Complex Conversation Primary Program PROGC 


Line 


START 
BALR 
USING 


RO,PRIMRIB 


(1), (0) 


RO,=CL6'SURJOB' 
(1),PROG,®,ACT,DATA 


RO,ACTMSG 


Description 


LOADING THE CDIB 
Load address of the following CDIB into R1: 
PRIMCDOIB CDIB FILENAME=PRIMARY 
OPEN CONNECTION TO SURROGATE 
Load address of the following RIB into RO: 
PRIMRIB RIB USE=PROG,HOSTID=ISLC 
WKFM=VARI 


Open session path 
Check for successful open 


SELECT THE SURROGATE PROGRAM 


Load surrogate program name into RO 
Select surrogate program 


Check for successful open 





Load address of ACTivate DATA 


Figure 9-9. Job Control and Coding for Example 5 (Part 1 of 3) 
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BAL Program for the Complex Conversation Primary Program PROGC 


— 


Line Description 


3c DMOUT (1),(0),UNLOCK Issue ACTIVATE 
Check for successful ACTivate 
ISSUE INPUT REQUEST TO GET REPLY FROM SURROGATE 


RO,RPLYAREA Load address of reply are into RO 


(1), (@) Wait for surrogate reply 
Check whether reply was received 


ISSUE BEQUEATH TO SURROGATE 


(1),PROG,BEQ Indicate BEQueath 


RO, BEQMSG Load address of BEQueath data 
(1),(®) Send data message — No reply required 
PREPARE TO RECEIVE DATA FROM THE PRIMARY 





RO, INPTAREA Load address of input area 


(1), (@) Get data from primary 
Check for successful read 


IF REPLY |S REQUIRED, SEND REPLY TO PRIMARY 


RO, INPTAREA Load address of reply area 
(1), (9) Reply to primary 
Check for successful reply 
Loop to get more input (DMINP performed) 
CHECK WHICH EXCEPTION FLAGS ARE SET IN CDIB 





Figure 9-9. Job Control and Coding for Example 5 (Part 2 of 3) 
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S BAL Program for the Complex Conversation Primary Program PROGC (cont) 


Line Description 


9C DMCTL (1),PROG,END Indicate REPLY END after receiving DEACTivate 


RO, INPTAREA Load address of reply 


DMOUT (1),(0) Reply to primary 
Check for successful reply 


CLOSE CONNECTION TO PRIMARY 


DCLOSE (1) Close session path 


Check for successful close 





Figure 9-9. Job Control and Coding for Example 5 (Part 3 of 3) 


9.5.6.3. Example 6: Complex Conversation Surrogate Program Receiving a 
BEQueath and Repeatedly Transferring Data 


Figure 9-10 shows the surrogate program issuing a DOPEN and receiving an ACTivate 
message from the primary program shown in Figure 9-9. After replying, it receives a 
BEQueath from the primary program and, as the new primary, sends 500 messages to 
the new surrogate, checking proper receipt after each 50 messages. It issues a 
DEACTivate message to the new surrogate program and, after receiving a reply, END, it 
terminates the conversation. 
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Job Control Required 


// JOB SURJOB 


// EXEC load module name 


BAL Program for the Complex Conversation Surrogate Program PROGD 


Line 
PROGD START 0 
BALR R15,0 


USING °,R15 


Description 


LOADING THE CDIB 





LA R1,SURCDOIB Load address of the following CDIB into R1: 
é SURCDIB CDIB FILENAME=SURRGATE 
ATTACH TO THE PRIMARY 


RO, SURRIB Load address of the following RIB into RO: 
SURRIB RIB USE=PROG ,WKFM=VARI 


DOPEN (1),(@) Attach to primary session 
Check for successful attachment 


GET ACTIVATE MESSAGE FROM THE PRIMARY 


RO, INPTAREA Load input area into RO 


DMINP (1),(6) Get input from primary 
Check for successful input 
REPLY TO PRIMARY 





RO, INPTAREA Load input area into RO 





Figure 9-10. Job Control and Coding for Example 6 (Part 1 of 3) 
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BAL Program for the Complex Conversation Surrogate Program PROGD (cont) 


Line 


3D 


SENDLOOP 
LOOP 1 
Loop2 


DMOUT 


LA 


(1), (0) 


RO, INPTAREA 
(1), (®) 


R9,10(0,0) 
R8,49(0,9) 
DATAAREA(84), 
DATAMSG 


(1), (@) 


R1,LOOP2 


RO, DATAAREA 
(1), (0), UNLOCK 


RO,RPLYAREA 


Description 


Reply to primary 


Check for successful reply 


RECEIVE BEQUEATH FROM PRIMARY 


Load address of input area 
Get message from primary 


Check whether BEQueath was specified 


ENTER DATA TRANSFER LOOP 


‘Loop2 is executed 49 times and 
a reply is expected on the 50th message. 


Set Loop1 counter (R9) 
Set Loop2 counter (R8) 


Load address of data area 


Send data w/o request for reply 


Check for successful send 


Loop through 49 times 
UP MESSAGES FOR WHICH REPLY IS REQUIRED 


Load address of data area 
Send message and wait for reply 


Check for successful send 


GET REPLY FROM SURROGATE AND CHECK VS LAST 
MESSAGE SENT 


Load the reply area 





Figure 9-10. Job Control and Coding for Example 6 (Part 2 of 3) 
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Line 


7D DMINP (1),(0) 


R9,LOOP1 


RO,=CL7'PRIMJOB' 
(1),PROG, (0), 
DEACT,DATA 


RO,DATAMSG 
(1), (@) ,UNLOCK 


RO,RPLYAREA 
(1), (0) 


DCLOSE (1) 


Figure 9-10. Job Control and Coding for Example 6 (Part 3 of 3) 


BAL Program for the Complex Conversation Surrogate Program PROGD (cont) 








Description 


Get the reply 


Check for successful reply 
Loop 1 
(cont) 


lf check positive, loop through 10 times 
TERMINATE CONVERSATION WITH SURROGATE 
Load surrogate program name 


Issue DEACTivate 
Check for successful DEACTivate 


Load address of DEACTivate message 
Issue DEACTivate message 
Check for successful DEACTivate 


CHECK WHETHER REPLY TO DEACTIVATE MATCHES 
MESSAGE SENT TO SURROGATE 





Load address of reply area 

Get the reply 

Check whether reply was received 
CHECK THAT REPLY END WAS RECEIVED 
TERMINATE ATTACHMENT TO SURROGATE 

Detach from the surrogate 


Check for successful detachment 
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t 9.5.6.4. Example 7: Primary Program Simultaneously Transferring Data During 
Complex Conversation with Three Surrogate Programs on Three Different 
Hosts 


Figure 9-11 shows a primary program simultaneously transferring 50 messages to three 
surrogate programs on three different, remote hosts. 


Job Control Stream Required 


// JOB PTPSPRIM 


// EXEC load module name 


@& BAL Program for the Complex Conversation Primary Program PROGE 


Line Description 
PROGE START 


R15, 
*,R15,R12,R11,R10 


BUILD THREE CDIBs FOR PROGRAM-TO-PROGRAM 
OPERATION 


LOOPSTRT EQU * 

LA R1,CD1B1 Load address of CDIB1 into R1 
USING CDSDCIB,R1 

BLDCOIB FILENAME=PRIME1,MSGSUP=NO 

LA R1,CDIB2 Load address of CDIB2 into R1 
BLOCDIB FILENAME=PRIME2,MSGSUP=NO 

LA R1,CDIB3 Load address of CDIB3 into R1 
BLDCDIB FILENAME=PRIME3,MSGSUP=NO 





@ Figure 9~11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 1 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 


Line 


RO,RIB1 


R1,CDIB1 


(1), (0) 


RO,RIB2 


R1,CDIB2 


(1), (0) 


RO,RIB3 


R1,CDIB3 


(1), (8) 


RO,=CL8'PTP$SRG1' 
R1,CDIB1 
(1),PROG, (0), 
ACT, DATA 


RO, =CL8'PTPSSRG2! 
R1,CDIB2 
(1),PROG,(®), 
ACT,DATA 








Description 


OPEN A CONNECTION TO EACH SURROGATE 


Load address of the following RIB1 into RO: 


RIB1 RIB USE=PROG, HOSTID=NOD4 
WK FM=VARI 


Load address of the following CDIB1 into R1: 
CDIB1 CDIB 
Open connection 


Check for successful open 


Load address of the following RIB2 into RO: 
RIB2 RIB 

Load address of the following CDIB2 into R1: 
CDIB2 CDIB 

Open connection 


Check for successful open 





Load address of the following RIB3 into RO: 
RIB3 RIB 

Load address of the following CDIB3 into R1: 
CDIB3 CDIB 

Open connection 


Check for successful open 


SELECT EACH SUROGATE PROGRAM 


Load surrogate program name into RO 
Load address of CDIB1 into R1 


Select surrogate program 


Check for successful select 


Load surrogate program name into RO 


Load address of CDIB2 into R1- 


Select surrogate program 





Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 2 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 


Line Description 


RO,CL8'PTPS$SRG3! Load surrogate program name into RO 


R1,CD1B3 
(1),PROG, (0), 
ACT,DATA 


RO, ACTVMSG1 
R1,CDIB1 
(1), (0), UNLOCK 


RO, ACTVMSG2 
R1,CDIB2 
(1), (0) ,UNLOCK 


RO, ACTVMSG3 
R1,CD1B3 
(1), (@), UNLOCK 


RO,RPYAREA1 


R1,CD1B1 
(1), (0) 


RO,RPYAREA2 


R1,CDIB2 


Load address of CDIB3 into R1 


Select surrogate program 


Check for successful select 


SET UP DATA FOR ACTIVATE COMMAND 


Load activate data message into RO 
Load address of CDIB1 into R1 
Issue ACTivate 


Check for successful ACTivate 


Load activate data message into RO 
Load address of CDIB2 into R1 
Issue ACTivate 


Check for successful ACTivate 


Load address of CDIB3 into RO 
Load address of CDIB3 into R1 
Issue ACTivate 


Check for successful ACTivate 


ISSUE INPUT REQUEST TO GET REPLY FROM 
SURROGATE 


Load address of reply area into RO 


Load address of CDIB1 into R1 
Wait for surrogate reply 


Check for successful reply 


Load address of reply area into RO 


Load address of CDIB2 into R1 





Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 3 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 


Line 


DMINP (1),(@) 


RO,RPYAREA3 


LA R1,CDIB3 
DMINP (1),(0) 


R9,10(0,0) 
R8,49(0,) 
MSGCOUNT(4), 
=PL4'10' 


RO, DATAREA1 
R1,CDIB1 
(1), (@) 


RO, DATAREA2 
R1,CDIB2 
(1), (0) 


RO, DATAREA3 
R1,CDIB3 


Description 
Wait for surrogate reply 


Check for successful reply 


Load address of reply area into RO 


Load address of CDIB3 into R1 
Wait for surrogate reply 


Check for successful reply 


ENTER DATA TRANSFER LOOP 


Loop2 is executed 49 times and a reply 
is expected on the 50th message. The 
reply must match the 49th message. 


Set LOOP1 counter (RQ) 
Set LOOP2 counter (R8) 


Update message counter 


Load address of data area into RO 
Load address of CDIB1 into R1 
Send data — w/o request for reply 


Check for successful send 


Load address of data area into RO 
Load address of CDIB2 into R1 
Send data — w/o request for reply 


Check for successful send 


Load address of data area into RO 


Load address of CDIB3 into R1 





Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 4 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 


Line Description 


(1), (@) Send data — w/o request for reply 


Check for successful send 


R8,LOOP2 Loop through 49 times 


UP MESSAGE FOR WHICH A REPLY IS EXPECTED 
RO,DATAREA1 Load address of data area into RO 
R1,CDIB1 Load address of CDIB1 into R1 
(1) ,(@), UNLOCK Send data — request reply 


Check for successful send 


RO, DATAREA2 Load address of data area into RO 
R1,CDIB2 Load of CDIB2 into R1 
(1), (0) ,UNLOCK Send data — request reply 


Loop 1 Check for successful send 
(cont) 


RO, DATAREA3 Load address of data area into RO 
R1,CDIB3 Load address of CDIB3 into R1 
(1), (0) ,UNLOCK Send data — request reply 


Check for successful send 


GET REPLY FROM SURROGATE CHECK IT AGAINST 
LAST OUTPUT MESSAGE SENT 


RO,RPYAREA1 Load address of reply area into RO 


R1,CDIB1 Load address of CDIB1 into R1 
(1), (0) Get the reply 


Check for successful reply 





Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 5 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 


Line 


RO, RPYAREA2 


R1,CDIB2 
(1), (0) 


RO, RPYAREAS 


R1,CDIB3 
(1), (@) 


R9, LOOP’ 


RO,=CL8'PTP$SRG1' 
R1,CDIB1 
(1),PROG, (0), 
DEACT, DATA 


RO,=CL8'PTP$SRG2' 
R1,CDIB2 

(1), PROG, (®), 
DEACT,DATA 


RO, =CL8'PTP$SRG3' 
R1,CDIB3 

(1), PROG, (0), 
DEACT,DATA 


Description 


Load address of reply area into RO 


Load address of CDIB2 into R1 
Get the reply 


Check for successful reply 


Load address of reply area into RO 


Load address of CDIB3 into R1 
Get the reply 


Check for successful reply 


Loop through 10 times 


TERMINATE THE CONVERSATION WITH THE 
SURROGATE PROGRAM 


Load surrogate program name with a RO 
Load address of CDIB1 into R1 
Select surrogate program 


Check for successful select 


Load surrogate program name into RO 
Load address of CDIB2 into R1 
Select surrogate program 


Check for successful select 


Load surrogate program name into RO 
Load address of CDIB3 into R1 
Select surrogate program 


Check for successful select 





Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 6 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 


Line Description 


SET UP DATA FOR DEACTIVATE MESSAGE 


RO, DACTMSG1 
R1,CDIB4 
(1), (®) , UNLOCK 


RO, DACTMSG2 
R1,CDIB2 
(1), (0) ,UNLOCK 


RO, DACTMSG3 
R1,CDIB3 
(1), (0), UNLOCK 


RO,RPYAREA1 


R1,CDIB4 
(1), (0) 


RO,RPYAREA2 


R1,CDIB2 
(1), (0) 


LOAD address of DEATCTivate message into RO 
Load address of CDIB1 into R1 
Issue DEACTivate 


Check for successful DEACTivate 


Load address of DEACTivate message into RO 
Load address of CDIB2 into R1 
Issue DEACTivate 


Check for successful DEACTivate 


Load address of DEACTivate message into RO 
Load address of CDIB3 into R1 

Issue DEACTivate 

Check for successful DEACTivate 


CHECK IF REPLY TO DEACTIVATE MATCHES 
MESSAGE SENT TO THE SURROGATE 


Load address of reply area into RO 


Load address of CDIB1 into R1 
Wait for the reply 
Check whether REPLY (END) was received 


Load address of reply area into RO 


Load address of CDIB2 into Ri 
Wait for the reply 
Check whether REPLY (END) was received 





Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 7 of 8) 
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BAL Program for the Complex Conversation Primary Program PROGE (cont) 





. 


Line Description 
LA RO,RPYAREAS Load address of reply area into RO 
LA R1,CDIB3 Load address of CDIB3 into R1 
DMINP (1),() Wait for the reply 


Check whether REPLY (END) was received 


CLOSE CONNECTION TO SURROGATE PROGRAM 


LA R1,CDIB1 Load address of CDIB1 into R1 
DCLOSE (1) Close the connection 

Check for successful close 
LA R1,CDIB2 Load address of CDIB2 into R1 
DCLOSE (1) Close the connection 


Check for successful close 


LA R1,CD1B3 Load address of CDIB3 into R1 


DCLOSE (1) 


Close the connection 


BCT R7,LOOPSTRT Loop for execution count 
EOJ End of job 

CDIB1 DC XL48'0@' 

CDIB2 DC XL48'09' 

CDIB3 DC XL48' 09! 

RIB1 RIB USE=PROG, HOSTID=NOD4, WKFM=VARI 

RIB2 RIB USE=PROG, HOSTID=NOD4, WKFM=VARI 

RIB3 RIB USE=PROG, HOSTID=NOD4, WKFM=VARI 


Figure 9-11. Job Control and Coding for Primary Program and Three Surrogate Programs for Example 7 (Part 8 of 8) 
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@ 9.5.6.5. Example 8: Typical Surrogate Program Used During Complex 
Conversation with the Primary Program of Example 7 


Figure 9-12 shows a typical surrogate program used along with two other surrogate 
programs simultaneously conversing with the primary program shown in Figure 9-11. 


Job Control Stream Required 


// JOB PTPSSRGn {where n is 1, 2, or 3) 


// EXEC load module name 


BAL Program for the Complex Conversation Typical Surrogate Program PROGF 


@ Line Description 


PROGF START 


R15, 
*,R15 
LOADING THE CDIB 
R1,SURCDIB Load address of the following CDIB into RO: 
SURCDIB CDIB FILENAME=PTPS$SRGn 


RO, SURRIB Load address of the following CDIB into RO: 
SURRIB RIB USE=PROG,WKFM=VARI 
ATTACH TO THE PRIMARY 





(1), (0) Attach to the primary session 
Check for successful attachment 
GET ACTIVATE MESSAGE FROM PRIMARY 
RO, INPTAREA Load address of input area into RO 





Figure 9-12. Job Control and Coding for a Typical Surrogate Program for Example 8 (Part 1 of 3) 
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BAL Program for the Complex Conversation Typical Surrogate Program PROGF (cont) 


Line 


DMINP (1),(@) 


RO, INPTAREA 
(1), (0) 


RECVLOOP RO, INPTAREA 


(1), (0) 


Recvloop 


RECVLOOP 


RO, INPTAREA 
(1), (®) 


RECVLOOP 


Description 
Get input from primary 


Check for successful input 


REPLY TO PRIMARY 
Load input area into RO 
Reply to primary 


Check for successful reply 


PREPARE TO RECEIVE DATA FROM PRIMARY 


Load address of input area into RO 


Get data from primary 
Recvloop 


Check for successful read 


1F A REPLY IS REQUIRED, SEND REPLY TO PRIMARY 


Continue loop if no flags are set 


Load address of reply into RO 
Reply to primary 


Check for successful reply 


Loop to get more input 





Figure 9-12. Job Control and Coding for a Typical Surrogate Program for Example 8 (Part 2 of 3) 
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BAL Program for the Complex Conversation Typical Surrogate Program PROGF (cont) 


Line Description 


CHECK WHICH EXCEPTION FLAGS ARE SET IN CDIB 


Check whether DEACTivate was received 


REPLY TO THE DEACTIVATE FROM THE PRIMARY 
(1),PROG,END 


RO, INPTAREA Load address of reply into RO 


(1), (0) Reply to primary 


Check for successful reply 


TERMINATE ATTACHMENT TO PRIMARY 
®& DCLOSE Detach from the primary 


SURCDIB FILENAME=PTP$SRGn (where n is 1, 2, or 3) 
SURRIB USE=PROG,WKFM=VARI 
INPTAREA XL' input-area-size' 





Figure 9-12. Job Control and Coding for a Typical Surrogate Program for Example 8 (Part 3 of 3) 


9.5.6.6. Complex Conversation Procedures Flow Diagrams 


Figure 9-13 shows all of the procedures available for DDP complex conversation and 


the possible combinations you might use in designing a communicating program pair. 
For further description, see subsection 9.5.4. 
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PROGRAM STARTING AS PRIMARY PROGRAM STARTING AS SURROGATE 


STEP STEP 
I 

1A (EXAMPLE 4) (EXAMPLE 4) 1B 

1C (EXAMPLE 5) (EXAMPLE 6) 1D 















DATA/CONTROL 
TRANSFER 

















= 
= 
ae 
~s -_ 
S Ped 
- 
> 
DATA/CONTROL = DATA/CONTROL 
TRANSFER _- ~ TRANSFER 
PHASE - ~Y PHASE 
~ ms 
~ 
| 
| al 
! 

PRIMARY SURROGATE 
CONVERSATION CONVERSATION 
TERMINATION TERMINATION 

PHASE PHASE 

1 
| 

LEGEND: 


Large circle C) indicates the imperative macroinstruction shown can be issued. 
When the program starting as primary reaches the @ state, it continues from the surrogate diagram state @ : 


When the program starting as surrogate reaches the (1) state, it continues from the primary diagram state @. 


Figure 9-13. Complex Conversation Procedures Flow Diagrams 
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Appendix A. Sample DDP File Copy/ 
Job Submission Session 


The following example shows a typical file copy and job submission from a local to a 
remote host. We have divided the example into parts for easy explanation. 


White print on a black background indicates entries the user makes. 


m Part 1: Logging on the system and mounting the disk volume 


LOGONAJSMITH 
LOGON ACCEPTED date time 
DDP TALKAMESSAGE='PLEASE MOUNT VOL@@7'AUSER=HO01: :OPERATORAWAIT 





DDP@O2 CAI @@2 TALK COMMAND ACCEPTED WO=000001 10:15:49 
DDP@22 TRM @22 TALK COMMAND COMPLETED WO=000001 10:15:59 
H@@1:SYSCON VOLUME MOUNTED. PROCEED. 


au fFWN = 


Explanation: 
1. This command attaches our job to the system. JSMITH is our user-id. 
2. The LOGON command is accepted at the indicated date and time. 
3. We tell the remote operator to mount our disk volume. 
4. The DDP TALK command is accepted. 
5. The DDP TALK command is completed. 


6. The remote operator responds to the DDP TALK command telling us he 
has mounted our volume. 
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Part 2: Allocating file space on the remote host and copying the file 

1. (DSN a OOS EP 

2. FEES 

3. DDPOO2 CAI @@2 CREATE COMMAND ACCEPTED WO=000002 10:20:37 

4. DDP@22 mmm @22 CREATE COMMAND COMPLETED WO=000002 10:25:51 

SMEDDP COPYAFROM=' , PERSNNEL ( JMS8/) 'ATO=HOO1::',REM/PERS 'H& 

6. 

7. DDP@O2 CAI @@2 COPY COMMAND ACCEPTED WO=000003 10:37:21 

8. DDPO22 mmm 022 COPY COMMAND COMPLETED WO=000003 10:42:39 

Explanation: 

1. We allocate space on our remote host HOOQ1 for our file, which we name 

and REM/PERS. We give it read and write passwords (AXS9 and AXSA/7). In 

2. the next command, we're going to be copying one of our local files to this 
file. So we have to establish the same block and record sizes as we have 
in our local file (182 and 91 characters, respectively). This command uses 
the defaults for DEVICE—CLASS, FILE—TYPE, INITIAL—SIZE, 
INCREMENT—-SIZE, RECORD—FORM, and REGISTER. 

3. The DDP CREATE command is accepted. 

4. The DDP CREATE command is completed. Our file is now established and 
cataloged on the remote host. 

5. We copy our local file, PERSNNEL, whose read password is JMS8, on our 

and remote host HOO1 in our remote file REM/PERS. If a direct connection 

6. isn't possible immediately, we want the system to hold the command until 
it is. This command uses defaults for the POSITION and TRANSLATE 
parameters. 
This line also shows the method for breaking a line using character string 
concatenation. 

7. The DOP COPY command is accepted. 

8. The DDP COPY command is completed. 

















UP-8811 Rev. 1 SPERRY UNIVAC 0S/3 A-3 
DISTRIBUTED DATA PROCESSING 


m Part 3: Sending the job to the remote host 





1. PSPS 

2. DDPOO2 CA 02 STATUS COMMAND ACCEPTED WO=000004 10:49:01 

3. WAITING FOR I/O 

4. DDPO22 mmm 922 STATUS COMMAND COMPLETED WO=000004 10:52:16 

5. (CORSET ee se oe 

6. DDPO@O2 CA 602 SUBMIT COMMAND ACCEPTED WO=000005 11:01:45 

7. DDPO44 mmm mid H6010035 JOB SUBMITTED FOR WO=000005 11:01:52 
Explanation: 


1. We want to find out what has happened to a job we submitted in a 
previous session. 


2. The DDP STATUS command is accepted. 
3. The job is being executed and is currently waiting for 1/0. 
4. The DDP STATUS command is completed. 


5. We submit the job in module PAYO6, located in library file PAYJOBS, to 
the remote host HOO1. 


6. The DDP SUBMIT command is accepted. 
7. Our job name is HOO10035 (renamed by DDP on remote system). 


8. We have successfully exited from DDP and can now use our terminal for 
some other task. 
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Appendix B. Command Function 


Summary 


Table B—1._ Command Function Summary (Part 1 of 4) 


To do the following: Use this With these 
command: parameters: 
Cancel a job DDPACANCELAJOB= 


on a specific host-id 
host 


with a job name of jobname 


& where you want ens 
the job's output to DELIVER 


be discarded or 
delivered to you 


Cancel a command ACOHMAND= (te 
on a specific host 


with work-order- work-order -number 
number of 


a file DDPACOPYAFROM= 


on a specific \ pees host - i 
host 


with a file-id of source-file-id 

to a host ATO= 

with a host-id of i i hosts idyes 
to a file with destination-file-id 

an id of 


where the source AELEMENT_TYPE= 


file has an element RELOCATABLE 


type ABSOLUTE 
MACRO 
PROC 


& COMPILED_JOB 
SCREEN _FORMAT, 





also: 


UP-8811 Rev. 1 SPERRY UNIVAC OS/3 B-2 
DISTRIBUTED DATA PROCESSING 





Table B-1. Command Function Summary (Part 2 of 4) 


To do the foliowing: Use this With these Required See 
command: parameters: also: 


Copy a file DDPACOPYAFROM= 





with an index that's AKEY | _ {3} =/size, location 
being changed from < A{DUPLICATES 
the original 


with a specification 
of how the copy is 

to be performed INDIRECT 
that should over- APOSITION= 

write current file 

contents (SOF) or add 

to current file 

contents (EOF) 


that needs trans- ATRANSLATE={ ASCII 
lating to the host's 

code 

Create a file DDPACREATEAFILE= 


on a specific { 
host E 





with a file-id of file-id 


with a specific 


) SH pPenee Heer gag Pr aene se) 
block size 


with a specific ADENSITY=(200 
tape density 


on a specific ADEVICE_CLASS=(®@ 
device 


re | 


with a specific AFILE_TYPE={ SEQUENTIAL 
file type INDEXED 

LIBRARY 
extention 


with a size for Srey toneny 


with an_ initial AINITIAL_SIZE= 
size 
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Create a file 


with a new index 


with a specific 
tape parity system 


with a specific 
record form 
with a specific 
record size 


that’s either 
cataloged or not 


Purge a file 


on a specific host 


with a file-id of 
Find out the status 


of a command you 
entered 


of a file you 
control 


of a host 
of a job you 


entered 


of another user 


Submit a job for 
execution 


from a specific 
host 


where the job is 
located in a specific 
file 
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Table B~1._ Command Function Summary (Part 3 of 4) 


To do the following: 


Use this 
command: 


With these 
parameters: 


: See 
R d 
sia ual also: 


DDPACREATEAFILE= 


AKEY +1 =/size, location 
: “tf Pp TE 


[* tie 

APARITY= {ODD 
EVEN 
ARECORD_FORM= {| 
VARIABLE 

UNDEFINED 


iets | iene 
Spe OI VERS io 


DDPAPURGEAF ILE= 


(eoewuas 


file-id 
DDPASTATUSACOMMAND= 


work -order -number 


AFILE=/ {hose ig 


file-j 
[keyword parameter] 


AHOST=host- id 
a8 |i 
jobname — 
AUER ee 
pecretd ; 


DDPASUBMI TAF ILE= 


file-id 








UP-8811 Rev. 1 SPERRY UNIVAC OS/3 B—4 
DISTRIBUTED DATA PROCESSING 


Table B-1._ Command Function Summary (Part 4 of 4) 


To do the following: Use this With these Required See 
command: parameters: also: 
Submit a job for execution DDPASUBMITAFILE= 
where the job in AELEMENT_TYPE= | 
the file has an element COMPILED_JOB 
type not specified in 


the file-id 


to a specific host AnOST={ destination host-id} 


a statement DDPASUBMI TAREQUEST= 


where you make a statement 
specific request 


to a specific host HOST eeu aa 


a message DDPATALKAMESSAGE= 


where the message ‘string’ 
is 


to a user or AUSER= 
operator 


located on a (eae -id 
specific host 


who is either penal 
the operator or user-id 
a user with an id 


where you want a AWAIT 
reply 




















UP-8811 Rev. 1 SPERRY UNIVAC OS/3 C-1 
DISTRIBUTED DATA PROCESSING 


Appendix C. Command Format 
Summary 






aa ig t- 


id el aaa 


eens C } ACOMAND= (ae :: Jwork-order -number 
DELIVER 


popaconvarnO | me fame tee 








ATO= [eae host- a joo ee 


AELEMENT_TYPE= 
RELOCATABLE 
@ ‘ABSOLUTE 





‘MACRO 

PROC 
COMPILED_JOB 
SCREEN FORMAT 


cil “| {aH a 
a p 









AMODE 
WAIT | 
INDIRECT 

ae 





ieee 





UP-8811 Rev. 1 


epeenerie rly 








SPERRY UNIVAC OS/3 
DISTRIBUTED DATA PROCESSING 


fee 


eae SIZE={number -of-characters/1-9 | 


— 200 


ns 


Sains AS 


a 





TAPE 

DISKETTE 

AFILE_TYPE= (SEQUENTIAL 
INDEXED 

LI 


BRARY 





number -of -blocks/1-9 ada 









mber -blocks/1-9 es | 


ze, Location — i 
ee \ 








APARITY= i 


ie 
ARECORD_FORM= 


[ 
| 
tale 
[ 


or SIZE= {i 


saan, 


da ala 


DDPASTATUSA { COMMAND=work - 


ea ho 


HOST=host- id 





ve ees id 


aan |i 














VARTABLE 
UNDEFINED 


max imum-number -of-characters/1-5 || 


i alae 


order -number 


ie ae 


al ei 
d a ee 
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Bee 


ie | 





—_—m€ ro 
leashes 


jee 


DDPASUBMI TAREQUEST= 





COMPI ell 


| 


‘statement! == ] 


\ eee A[WAIT] 
user-id 








tinati 












DDPATALKAMESSAGE='string Se 
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& Appendix D. Operator's Distributed Data Processing 
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D. OPERATOR’S DISTRIBUTED DATA PROCESSING REFERENCE (SEPARABLE) 


D.1. 


D.2. 
D.2.1. 
D.2.2. 
D.2.3. 
D.2.4. 
D.2.5. 
D.2.5.1. 
D.2.5.2. 
D.2.5.3. 
D.2.5.4. 
D.2.5.5. 
D.2.6. 
D.2.7. 
D.2.8. 
D.2.9. 
D.2.10. 
D.2.11. 
D.2.12. 
D.2.13. 


OVERVIEW 


DISTRIBUTING FILES AND JOBS: THE DDP TRANSFER FACILITY 


What You Need to Do for DDP Transfer Facility Users on Your Computer 


How DDP Transfer Facility Users Get Their Output 
Requests to You from Remote DDP Users 
Entering and Leaving the DDP Transfer Software from the Console 
Special Terms in DDP Command Parameters 
Host-id 
File-id 
User-id 
Job Name 
Work Order Number 
Communicating with DDP Users (DDP TALK) 
Creating a File on a Remote Host (DDP CREATE) 
Copying Files or Modules (DDP COPY) 
Purging Files (DDP PURGE) 
Sending Jobs to a Remote Host (DDP SUBMIT FILE) 
Cancelling a Job or Command (DDP CANCEL) 
Sending a Request to a Remote Host (DDP SUBMIT REQUEST) 
Finding Out the Status of a DDP Command, Host, User, File, or Job 
(DDP STATUS) 


D-3 


i 
=OOVNNOARARA RWW 


| 
NR 


Oe OS ao ee ea 
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D.1. OVERVIEW 

You distribute your data processing when you perform different computer tasks on 
different independent computers but, at the same time, link those computers together 
so that they can use each other's resources. There is a series of SPERRY UNIVAC 
products that make it easy to send jobs, files, transactions, requests for data and 
communicate via your application program from one computer to another. These 
products make distributed data processing (DDP) easy to use. 

D.2. DISTRIBUTING FILES AND JOBS: THE DDP TRANSFER FACILITY 


The first product in the SPERRY UNIVAC DDP line is the DDP transfer facility. It lets 
you: 


m™ send a message to someone at the remote computer; 

™ create files on a remote computer; 

= copy files from one computer to another; 

m  §=purge files on a remote computer; 

m send jobs to a remote computer and later cancel them if you need to; 

m send a system request to the remote computer; and 

m ~§=find out the status of a command you entered, a file you control, a host, a user, or 
a job you submitted. 

D.2.1. What You Need to Do for DDP Transfer Facility Users on Your Computer 


lf you have a user on your system who wants to use the DDP transfer facility, you have 
to make sure that the following are all true: 


= Spooling is configured. 


= ICAM is loaded, and the ICAM network includes the remote computer your DDP 
user wants to work with. 


m Interactive services is configured. 


The DDP software takes care of everything else. 
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D.2.2. How DDP Transfer Facility Users Get Their Output 


When your DDP users have jobs performed at a remote computer, the remote computer 
sends the output back to your spool file. From there it’s printed or punched, the same 
as any other output in the spool file. You should distribute it according to your current 
procedures. 


D.2.3. Requests to You from Remote DDP Users 

The DDP command language contains a DDP TALK command that lets remote DDP 
users send messages directly to you. They may want you, for instance, to mount a disk 
that they're going to be using or to remove that disk once they’re done. You can 


respond to them using the DDP TALK command also. See D.2.4 for information on how 
to enter the DDP software, and D.2.6 for the format of the DDP TALK command. 


D.2.4. Entering and Leaving the DDP Transfer Software from the Console 
If your terminal, workstation, or system console is connected to a DDP network (see 


1.3, 3.5, and 8.2), you enter DDP software whenever you issue a DDP software 
command and exit whenever your DDP command terminates. 


D.2.5. Special Terms in DDP Command Parameters 


D.2.5.1. Host-id 

Each host in your DDP network has a host identification (host-id). This is the same 
identification as the node-id you specify in the REMOTE parameter of the LOCAP 
macroinstruction in your ICAM network definition. 

The host-id is one to four alphanumeric characters long. The first character must be 
alphabetic. 

D.2.5.2. File-id 

The DDP transfer facility uses a specific form of file identification (file-id). It has a 
maximum of 74 characters and is always expressed as a character string (in 
apostrophes). 


Format: 


‘[module-name], filename[([read-passwrd]/[write-passwrd])1,[vol],[element]' 
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where: 


module-name 
Is used only when you're referencing just one module from a file. It is the one 
to eight alphanumeric characters identifying the module. It must begin with an 
alphabetic character. 


filename 
Is always required. It is the same as the name on the // LBL job control 
statement for the program. For disk files, it is 1 to 44 alphanumeric characters 
long. For tape files and logical files (spool files), it is 1 to 17 alphanumeric 
characters long. 


read-passwrd 

Is a password (one to six alphanumeric characters) enabling you to read the 
file. If omitted, the system assumes there is no read password on the DDP 
command. If the file does have a read password that you omit, you won't be 
able to read the file. Use only with cataloged files. 


write-passwrd 
Is a password (one to six alphanumeric characters) enabling you to write to the 
file. If omitted, the system assumes there is no write password on the DDP 
command. If the file does have a write password that you omit, you won't be 
able to write to the file. Use only with cataloged files. 


vol 
Is the volume serial number (one to six alphanumeric characters) of the volume 
on which your file resides. Specify this when the file is not cataloged. 


element 
Specifies the type of code contained in the program module you're sending. In 
OS/3, we'd normally call this ‘‘type’’ or ‘‘module-type’’. But since DDP is 
designed eventually to connect you with non-OS/3 hosts, we're using the 
word “‘element’’. 


The element types are the same ones you're familiar with for all OS/3 library 
files. SAT files may have the following types: 


m ~~ § (source code) 
[=| M (macro) 

=~ ~=6P (procedure) 

a LL (load code) 


m O (object code) 
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MIRAM files may have the following types: 

m  F or FC (screen format modules) 

m J (saved job control stream) 

m= MENU (menu modules) 

@ HELP (help screen modules) 

The default is S (source). 

For MIRAM files, you may create your own element type and identify it with 
one to four characters. (For further information on MIRAM files, see 
consolidated data management concepts and facilities, UP-8825 (current 


version). 


Table D—1 gives some examples of complete file-ids. 


Table D-1, Examples of File-ids 


Type of File 


A cataloged file with no read and ', SITE/3' 

write passwords 

A cataloged file with read and ' SITE/3(XX2674/BENNIS)'! 
write passwords 





A module from a cataloged file "PROG14, JOBFIL19(XX4982/RILEY) '#8& 
with read and write passwords Vo! 


An uncataloged file with a ' SITE/ACSMPRO) ,VSN149! 
write password but no read password 

An uncataloged file with a ', SITE/A&BCREAD/) , 296410! 
read password but no write password 


D.2.5.3. User-id 





The user-id is one to six alphanumeric characters identifying you as a user to the host. 
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D.2.5.4. Job Name 

When you enter a DDP SUBMIT FILE command, DDP returns a job name to you with 
which you can cancel the job if you later need to. DDP renames each job with a unique 
name with the format xxxxyyyy 


where: 


XXXX 
Is the four-character host-id of the host that initiated the command. 


yyyy 
Is the four-digit unique number. 


If you submit a file containing many jobs, DDP returns each job name to you in a 
separate message. 


The format for the job name message is: 


DDP@O4 EJS 044 xxxxyyyy JOB SUBMITTED FOR WO=work-order-number time 


See D.2.5.5 for an explanation of work order number. 


D.2.5.5. Work Order Number 


Once DDP accepts your command, it returns a work order number to you using the 
format: 


DDP@O2 CAI @@2 cccccccccc COMMAND ACCEPTED WO=nnnnnn time 


where: 


ecceccccccce 
Is the name of the command you've just entered. 


nnnnnn 
Is the work order number of the command. 


For instance, let's say you've just entered the DDP COPY command. DDP responds: 


DDP@O2 CAI 902 COPY COMMAND ACCEPTED WO=A48107 13:46:02 


Write down the work order number, since error messages use it for identification. If, for 
example, you enter a command that cannot be completed at the remote host, DDP 
informs you of the problem by sending you a message such as: 


DDP@O1 ELH @23 COPY COMMAND ABORTED WO=A48107 13:48:39 
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The WO=A48107 is the work order number that DDP returned to you at the time you 
entered your copy command. You may have entered several copy commands, but each 
has a different work order number, so you can tell them apart. 


D.2.6. Communicating with DDP Users (DDP TALK) 


Function: 


The DDP TALK command lets you send a message to a remote DDP user or to the 
operator of a remote system. 


Format: 






DDPATALKAMESSAGE='string' AUSER= i id }: ] eae ee 
t host. 3 user-id 


Positional Parameters: 


string 
Indicates a character string message you want the operator or user to get. 
Enclose it in apostrophes and double all enclosed apostrophes. 


host-id 
Is one to four alphanumeric characters naming the host where the operator or 
user is. See D.2.5.1 for additional details. 


OPERATOR 
Specifies the operator of the remote host. 


user-id 
Is one to six alphanumeric characters identifying the user to the system. 


WAIT 
Informs the operator or user that you want a reply. You do not, however, have 
to wait for this reply to go on with other commands. Your keyboard isn't 
locked during this period. 


If you receive a message with a WAIT indicated, you should reply as soon as 
possible. 


Example: 
Operator keyin: 


DDP TALK MESSAGE='VOL@@7 MOUNTED' USER=H@@1::CJONES 


User CUONES on host HOO1 has previously sent you a message asking to have 
VOLOO7 mounted. You reply that you have done so. 
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D.2.7. Creating a File on a Remote Host (DDP CREATE) 


Function: 
Use the DDP CREATE command to allocate space for a file on a remote host. 
Format: 


acetic | id |: joo 






aed | number -of-characters/1-9 digi || 


DENSITY=/200 
556 
860 
1600 
6258 


q 





DISKETTE 


FILE_TYPE=({ SEQUENTIAL 
INDEXED 
LIBRARY 





er SIZE= { 





number -of -blocks/1-9 | 


pe: SIZE= Vem ga 


KEY ey ty size, location | eee H 
ee 
fs ie } 
ae 


io 














VARIABLE 
UNDEFINED 


RECORD_SIZE= ieee) geen cd 








om VTOC } 
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Positional Parameters: 


host-id 
Is one to four alphanumeric characters that name the host you create the file 
on. See D.2.5.1 for additional details. 


file-id 
Is 1 to 74 alphanumeric characters identifying your file. See D.2.5.2 for 
additional details. 


Keyword Parameters: 





pp pear aerig ane ieee poe vane 


Is the number of characters in a block. 


DENSITY=/200 
556 
800 
1600 
6250 





Is the tape density in bytes per inch (bpi). 


DEVICE_CLASS= 





TAPE 
DISKETTE 
Is the device class that will contain your file. 


FILE_TYPE=/( SEQUENTIAL 
INDEXED 
LIBRARY 





Is the type of file being created. 





RTT ee nee 





Is the number o 
extend its size. 


ks of storage to be added to the file whenever you 





INITIAL_SIZE={ initial -number-of-blocks/1-9 oars 





Is the number of blocks initially allocated to the file. 
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othe" [al 
= 


Creates an index for the file on the receiving host. Specify one KEY—n 
parameter for each index key (to a maximum of five) you create. 






PARITY={ ODD 
EVEN 


Is the parity system for tape files. 





“eT 


VARIABLE 
UNDEFINED 


Specifies whether record length is fixed or variable. 


ane max imum-number -of-character/1-5 pen 





Is the maximum number of characters in a record. 


Either catalogs your file or registers it in the volume table of contents. 


VTOCc 





ser 


Example: 


Operator keyin: 


DDP CREATE FILE=H@01::',REM/PERS(AXS9/AXSA7) ,VOL@07' BLOCK_SIZE=182& 
RECORD_SIZE=91 


Creates a cataloged file on host HOO1, disk volume VOLOO7, that has read and 
write passwords, a block size of 182, and a record size of 91. Records are 


fixed. The file is smaller than three cylinders. FILE TYPE is UNDEFINED (the 
default). 
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D.2.8. Copying Files or Modules (DDP COPY) 
Function: 


The DDP COPY command duplicates either an entire file or a module from a file on 
another system. 


Format: 


ee rer 





aa 
ATO= [Saas host- ihe eetone ent 


AELEMENT_TYPE 





RELOCATABLE 
ABSOLUTE 
MACRO 

PROC 
COMPILED_JOB 
SCREEN_FORMAT 


aa I; size, location (as | 


i 











a IRECT 
fh 


INDIRECT 


nen {' | 
SOF 


ort 








NONE 


Positional Parameters: 


originating-host-id 
Is one to four alphanumeric characters naming the originating host. See D.2.5.1 
for additional details. 


originating-file-id 
Is 1 to 74 alphanumeric characters identifying the input file. See D.2.5.2 for 
additional details. 


destination-host-id 
Is one to four alphanumeric characters naming the host to receive the 
information. See D.2.5.1 for additional details. 
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destination-file-id 
Is 1 to 74 alphanumeric characters identifying your file. See D.2.5.2 for 
additional details. 
Keyword Parameters: 


ELEMENT_TYPE= 





RELOCATABLE 
ABSOLUTE 
MACRO 
PROC 
COMPILED_JOB 
SCREEN_FORMAT 
Is the element type of the module you are copying. 


atl size, location | DUPLICATES 
4 


Changes an index for ile on the receiving host. Specify one KEY—n 
parameter for each index key in the record (to a maximum of five), even if you 
change only one. 


MODE= 
WAIT 
INDIRECT 


Specifies whether the device or medium needed to copy the file at the 
destination host must be immediately available (DIRECT), whether you want to 
wait until it is available (WAIT), or whether you want to copy the file into a 
temporary file on the destination host if the device or medium needed to 
receive the copy is not available (INDIRECT). 


ie | 
SOF 


Specifies overwriting (SOF) or extending (EOF) of the destination file. 

















“ve {ee 


NONE 


Indicates the character code you want the file translated to as it arrives at the 
destination host. 


UP-8811 Rev. 1 SPERRY UNIVAC OS/3 


DISTRIBUTED DATA PROCESSING 





Example: 
Operator keyin: 
DDPACOPYAFROM=! , PERSNNEL ( JMS8/) 'ATO=H001::',REM/PERS(/ASXA7) 'AMODE=WAIT 


Copies file PERSNNEL into the blank cataloged file REM/PERS on host HOO1, 


which uses EBCDIC. If a direct connection isn’t possible, you want the system 
to hold the command until it is. 


D.2.9. Purging Files (ODP PURGE) 


Function: 


The DDP PURGE command physically removes a file or element and all references 
to it from a host. 


Format: 


DDPAPURGEAF ILE= [is -id 





a acl 


Positional Parameters: 


host-id 


Is one to four alphanumeric characters naming the host you are purging the file 
from. See D.2.5.1 for additional details. 


file-id 


Is 1 to 74 alphanumeric characters identifying the input file. See D.2.5.2 for 
additional details. 


Example: 
Operator keyin: 
DDP PURGE FILE=H@01::',REM/PERS(AXS9/AXSA7) ' 


Purges cataloged file REM/PERS on host HOO1. 
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D.2.10. Sending Jobs to a Remote Host (DDP SUBMIT FILE) 
Function: 


The DDP SUBMIT FILE command sends a file of jobs or a module to a remote host 
for execution. 


Format: 


a 


D_JOB i] 


AELEMENT_TYPE=( S¥MBi 
COMP 
oe ination-host- a“) 


Positional Parameters: 











originating-host-id 
Is one to four alphanumeric characters naming the job control stream file 
location. See D.2.5.1 for additional details. 


file-id 
Is 1 to 74 characters identifying your file. See D.2.5.2 for additional details. 


Keyword Parameters: 





rie 

COMPILED_JOB 

Is the element (module) type of the submitted file. SYMBOLIC indicates source 
code. COMPILED—VJOB indicates compiled job streams with expanded jprocs. 
You may omit this parameter if the element type is SYMBOLIC (the default) or 
if the element type is specified in the file name. Normally, you won't be using 
COMPILED—JOB. 


sisi (RAE 





Is one to four alphanumeric characters naming the host you submit the file to. 
If omitted, the command assumes the file is to be submitted to your local 
system. For more information about the host-id, see D.2.5.1. 
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Example: 
Operator keyin: 


DDP SUBMIT FILE='PAY@6,PAYJOBS(JMS17/),,S' HOST=HO61 


Submit the source code job in module PAYO6 of file PAYJOBS to remote host 
HOO 1. 


Alternate operator keyins to accomplish same task: 


DOP SUBMIT FILE='PAY@6,PAYJOBS( JMS17/)' ELEMENT_TYPE=SYMBOLIC. HOST=H901 
DDP SUBMIT FILE='PAY@6,PAYJOBS(JMS17/)' HOST=HOO1 


System Response: 


DDPO44 JNR 044 HO020038 JOB SUBMITTED FOR WO=000012 13:47:56 


Write down the job name (HOO020038) and its work order number (000012). 
You need them to cancel the job or to inquire as to its status. 

D.2.11. Cancelling a Job or Command (DDP CANCEL) 

Function: 


The DDP CANCEL command terminates an executing or backlogged job or a 
command executing on a host. 


Format: 





Sate | ok id 


: lee 
renee ] 


a \ | aaa 






Cala 





Positional Parameters: 


host-id 
Is one to four alphanumeric characters naming the host that the job is 
executing on. See D.2.5.1 for additional details. 


jobname 
Is the one to eight alphanumeric characters naming your job. See D.2.5.4 for 
additional details. 
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Keyword Parameters: 





a \ 

DELIVER 

Specifies whether you want the spooled output from the job erased from the 
spooled output files (DISCARD) or sent to the originating host (DELIVER). 





uae 







Spec s the command that you entered but now wish to cancel. 


work -order - number 
Is the one to six alphanumeric work-order-number that was displayed to you 
when command was accepted. 
Example: 


Operator keyin: 


DDP CANCEL JOB=HO01: >HOO20038. OUTPUT=DELIVER 


Cancels job HOO20038 on host HOO1. Any spooled output is returned to the 
originating host. 


D.2.12. Sending a Request to a Remote Host (DDP SUBMIT REQUEST) 


Function: 


The DDP SUBMIT REQUEST command lets you send an instruction for the remote 
host to perform some task. 


Format: 


host-id 






Pen vote eleseegenere | at 


Positional Parameters: 


statement 
Is the system command or message being submitted. Normally it is a character 
string enclosed in apostrophes. 


Keyword Parameters: 
HOST=host- id 


Is one to four alphanumeric characters naming the destination host. See 
D.2.5.1 for additional details. 
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Example: 





Operator keyin: 
DDP SUBMIT REQUEST='RU CGV, ,O=VSN999 ,N=186309,T=30' HOST=N852 


Submits a canned job control stream to host N852 to change the volume serial 
number on a disk. 


D.2.13. Finding Out the Status of a DDP Command, Host, User, File, or Job 
(DDP STATUS) 


Function: 


You can find out the status of a command you entered, a host in your system, a 
user, a file, or a job, by using the DDP STATUS command. 


Format: 


DDPASTATUSA{ COMMAND=work - order -number 
| host-id | 


HOST=host- id 
gi | ota 


ae 


Keyword Parameters: 





Ajeores ees parameter] 


} ] jobname 
host-id 


Eeree 















COMMAND=work - order - number 
Tells you the status of a command you entered. The response tells you the 
originating (primary) host, the destination (secondary) host, the time the 
command was sent, the time it was completed (if it was completed), and 
status information such as BEING PROCESSED, IN SCHEDULER, or 
COMPLETED. See D.2.5.5 for additional details about the work order number. 






ne eae ::)file-id 


Tells you the status of a library file or module on a host. See D.2.5.1 for 
additional details about the host-id. 


HOST=host- id 
Tells you how busy a host is by showing you the number of users (both local 
and remote), the number of buffers DDP is using and their size, and the 
number of DDP work orders currently being processed. See D.2.5.1 for 
additional details about the host-id. 
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aaa 


Tells you job status, such as COMPLETED, BEING PROCESSED, or IN 
SCHEDULER. See D.2.5.1 for additional details about the host-id. See D.2.5.4 
for additional details about the jobname. For restrictions, see 8.5.1. 





ye user-id 

Lists a table of the most recent DDP functions for a particular user. At a 
minimum, all commands that aren’t completed are listed. In addition, some 
completed commands are listed. See D.2.5.1 for additional details about the 
host-id. See D.2.5.3 for additional details about the user-id. 


As the system console operator, you may request the status of any user in the 
system. 


Example: 
Operator keyin: 


DDP STATUS. HOST=H901 


Inquires about how busy host HO0O1 is. 
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Appendix E. Command Requirements 


Certain DDP commands and parameters require the use of other commands or 
parameters. This table describes those requirements. 


Table E-1. Command Requirements (Part 1 of 2) 


If you specify: You must also specify: 


DDPACANCEL JOB= a job name for a job that you submitted through the SUBMIT FILE command 
with the same user-id 


S COMMAND= a command that you submitted with the same user-id that you wish to cancel 
DDPACOPY FROM= originating-file-id 
destination-file-id 
TO= 


file-id that includes a file-id must also include element type or you must specify the ELEMENT 
nonsource module name TYPE= parameter 


MODE=INDIRECT file must be cataloged 


For additional restrictions on this 
command, see Tables 8-3 and 8-4. 


DDPACREATE FILE= file-id 
BLOCK_SIZE= either INITIAL_SIZE or INCREMENT_SIZE or both 


DEVICE_CLASS=DISKETTE BLOCK_SIZE=256 or less 
RECORD_SIZE= 256 or less 


INCREMENT_SIZE= BLOCK_SIZE= 


INITIAL_SIZE= BLOCK_SIZE= 


KEY[_n]= either FILE_TYPE=INDEXED or FILE_TYPE= UNDEFINED (if you’re going to 
copy an indexed file into this file) 


PARITY= DEVICE_CLASS=TAPE 
® RECORD_FORM=UNDEF INED DEVICE_CLASS= TAPE 


REGISTER=VTOC file-id with a volume serial number included for all subsequent commands 
referring to this file 
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Table E-1. Command Requirements (Part 2 of 2) 


DDPASUBMIT FILE= file-id 





file-id that includes module file-id must also include element type or you must specify the 
name ELEMENT_TYPE= parameter 


DDPASUBMIT R | DDPASUBMIT REQUEST= | ST= statement } statement being submitted = } statement being submitted = 


DDPATALK Soren esr string being sent 
USER= 
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Appendix F. Entering DDP Commands 
in a Batch Stream 


F.1. OVERVIEW 


You usually use DDP as an interactive product. But you can submit DDP commands as a 
remote batch job. The advantage of doing so is that you can perform remote tasks 
using these relatively simple commands during periods when you can't be at the 
terminal, such as overnight. The disadvantage is that you don’t get your messages and 
output as promptly as you would if you were working interactively. Instead, all 
messages and output are printed at your local host for you to pick up. 


F.2. CARD FORMAT 


The following table shows the format for the cards required to enter your DDP task as a 
batch job. 


Table F—1. Entering DDP Commands in a Batch Stream (Part 1 of 2) 


// DATA FILEID=name name 
The name through which you _ reference this enter 
stream. It is one to eight alphanumeric characters long. 


LOGON user-id, Bus {aes user-id 
NO The one to six alphanumeric characters identifying you 
as a user to the host. 


Bute | 


U=YES prints the day’s bulletin on your output. The 
default is NO. Although you can’t change your DDP 
commands as a result of knowing the bulletin, knowing 
it may explain output errors. 
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Table F—1. Entering DDP Commands in a Batch Stream (Part 2 of 2) 





DDP command cards Type these on the cards exactly as you would type them in 
at your terminal. 


Because this is an enter stream, your DDP commands are 
executed in the order in which you list them. Each command 
is completed before the next is started. (This is different 
from terminal operation, where you can start your next DDP 
command before the previous one is complete.) Therefore, it's 
all right to list commands that depend on_ previous 
commands. For instance, you can first create a file and then 
copy to it. DDP won't attempt to copy before it creates the 
file. 


NOTE: 


Operations that proceed in a local-to-remote direction are done 
serially. However, operations in a _ remote-to-local, or 
remote-to-remote direction, are merely routed to the remote 
host for processing. As soon as routing is complete, the 
next command is executed. 


Care should be taken when performing these operations from 
an enter stream, since concurrent command execution may 
result. 





F.3. PROCEDURES 


Follow these steps to enter your DDP commands as a remote batch job: 
1. Place cards in the card reader. 
2. At the system console, enter: IN 


A message appears on the system console indicating that the file you specified on 
your FILEID parameter in the // DATA statement has been created. 


3. At the system console, enter: 


ENTERAQ=RDR,HOLD= 






a" 
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where: 
ee | 
Indicates whether the enter stream is to be retained by the host 
(HOLD=YES) or deleted once the stream has been processed 
(HOLD=NO). The default is HOLD=NO. 
name 


is the reference name of the enter stream as indicated in your FILEID 
parameter in the // DATA statement. 


Enter streams can also be created through the OS/3 editor and saved as source 
modules in a user library. They can be executed by typing the following command: 


ENTER module-name, type, filename,vsn 


For parameter specifications of the ENTER command, see the OS/3 general editor 
user guide/programmer reference, UP-8828 (current version). 


F.4. SAMPLE ENTER STREAM 


Here are the cards you'd use to enter the sample session from Appendix A in a remote 
batch enter stream. See Appendix A for explanations of any commands you don’t 
understand. 


// DATA FILEID=ARCHER 

LOGON JSMITH,BU=YES 

DDP TALK MESSAGE='PLEASE MOUNT VOL067' HOST=HO01::OPERATOR 

DDP CREATE FILE=H@01::',REM/PERS(AXS9/AXSA7) , VOL@O07' BLOCK_SIZE=182 RECORD_SIZE=91 
DDP COPY FROM=',PERSNNEL(JMS8/)' TO=HO001::',REM/PERS(/AXSA7)' MODE=WAIT 

DDP SUBMIT FILE='PAY@6,PAYJOBS(JMS17/),,S' HOST=HOO1 

LOGOFF 

// FIN 
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Appendix G. Logging Chart 


All DDP local and remote activity is automatically logged in the Interactive Services log 
file during shutdown processing. The log printout is normally sent to the central site 
printer. 


The following chart can be used to list your system assigned job number and any other 
pertinent data from your displayed log for accounting purposes. 


DDP LOG SHEET 


TERMINAL: 


UP-8811 Rev. 1 


Remote Host Time 
Completed Aborted 


Jobname 


. 
a 
] 
Ks 
lo] 
x 
< 
5 
= 


Accepted 


Command 
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Appendix H. Generating Your ICAM 
Network with DDP 


DDP requires ICAM’s demand mode interface (DMI) and distributed communications 
architecture (DCA). Your host-ids appear in the REMOTE parameter of the LOCAP 
macroinstruction. No other adjustments are required when you define your ICAM 
network. 


Here is a sample ICAM network definition that you could use with DDP. It’s a very 
simple one, with just two hosts and one user connected to one of the hosts on a 
terminal. For further information on using ICAM and DMI, see current versions of 
integrated communications access method (ICAM) concepts and facilities, UP-8194, and 
the integrated communications access method (ICAM) network definition and operations 
user guide, UP-8947. 


COMMCT 
ACT1 CCA TYPE=(GBL, JA) ,DCA=YES, GAWAKE=YES , CCAID=ACT1 ees eevour sera 
host, whose id is A 
BUFFERS 24,256,2,ARP=36, UDUCT=(6,24,2),LINKPAK=(45, 80,2) 
LNE1 LINE DEVICE=(UNISCOPE) , TYPE=(9600,UNAT, SWCH, SYNC) , ID=4 = 
ATRM TERM FEATURES=((U40d, 1920) , ADDR=(21,51) ,AUX1=(COP,21), po eae 
HIGH=MAIN, LOW=MAIN, MEDIUM=MAIN, INPUT=(YES) , TCTUPD=YES a 
7 = ~ = ere Ss wnere you 
cUP1 LOCAP TYPE=(DMI) ,MT=YES, IAS=(YES, OFF) me pacity OM 


VLN1 VLINE DEVICE=(ABM, PRIMARY), TYPE=(9600) , ID=7 
LPORT LINE=VLN1,REMOTE=(B) ,PORT=1,EU1=CUP1,EU2=CUP2, 
USERTP=(DMI) ,NUMSS=1 


TERM FEATURES=(U400, 1920) ,ADDR=(21,51) ,AUX1=(COP,21), 
HIGH=MAIN, LOW=MAIN,MEDIUM=MAIN, INPUT=CYES), 
TCTUPD=YES ,REMOTE=(B) 

LOCAP TYPE=(DMI),MT=YES, IAS=(YES, OFF) ,REMOTE=({B)) 

ENDCCA 


This is your remote 
host, whose id is B 


MCP 
MCPVOL=RELO71 
MCPNAME=C1 
CACH=(04,9600, SWITCHED, SYNC) 
CACH=(07, 9600, FULL, ILA) 
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Appendix |. DDP Program-To-Program 
Macroinstructions Summary 


The following (Table I-1) is a summary of the program-to-program macroinstructions 
used with the OS/3 DDP file access facility. 


Table I-1._ DDP Program-To-Program Macroinstructions Summary (Part 1 of 3) 


To do the following Issue this imperative 


Establish a communications path | DOPEN (1) | ‘ } 


between Primary IPC and cdibname ribname 
Destination IPC 


where: 


cdibname 
Address of user’s CDIB 


(1) 
CDIB address is preloaded into register 1. 


ribname 
Address of user’s RIB 


(®) 


RIB address is preloaded into register O. 


Begin and end a conversation ca (1) oe ne i ee ee 


between paired programs 


cdibname surrogate-prog DEACT 


where: 


cdibname 
Address of user’s CDIB 


(1) 
CDIB address is preloaded into register 1. 
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Table I-1. DDP Program-To-Program Macroinstructions Summary (Part 2 of 3) 


To do the following tssue this imperative 


Begin and end a conversation PROG 
between paired programs (cont) 





Identifies the imperative belongs to the 
DOP file access facility. 


surrogate-prog 
Name of the program with which conversation 
is to be initiated (used with ACT option only). 


(®) 
Assumes address of name of program is 
preloaded into register 0. 


ACT 
Indicates Primary program conversation with 
Surrogate program is to be activated. 


DEACT 
Indicates Primary program conversation with 
Surrogate program is to be deactivated (closed). 





DATA 
Indicates next imperative contains data to be 
passed with ACT or DEACT IPC function. 


Transfer data esa a es Leones 


DOMINP edibname workarea 


where: 


DMOUT 
Used to send data 


DMINP 
Used to receive data 


cdibname 
Address of user’s CDIB 


(1) 
CDIB address is preloaded into register 1. 


workarea 
Address of data buffer that can be fixed 





or variable according to the WKFM parameter 
description in the RIB. 











UP-8811 Rev. 1 SPERRY UNIVAC OS/3 I-3 
DISTRIBUTED DATA PROCESSING 





Table 1-1. DDP Program-To-Program Macroinstructions Summary (Part 3 of 3) 


To do the foliowing Issue this imperative 


Transfer data (cont) 
Buffer address is preloaded into register 0. 


UNLOCK 
Indicates reply required from Surrogate program 
(only issuable by Primary program) 


Pass conversation control OMCTL {‘ 1) peu dash 


from Primary program to cdibname END 
Surrogate program 


where: 


cdibname 
Address of user's CDIB 


(1) 
CDIB address is preloaded into register 1. 


PROG 
Identifies the imperative belongs to the 
DDP file access facility. 


Indicates conversation control is to be 


passed to the Surrogate program. 


Indicates an end to the conversation 
(only a DMOUT imperative can follow; 
indicates a reply is expected by the 
Primary program; usable only in TWA 
mode by the Surrogate program). 


Close the conversation pent (1) } 
cdibname 


where: 


cdibname 
Address of user's CDIB 


(1) 





CDIB address is preloaded into register 1. 
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Glossary 


A 


absolute code 
Load code. 


application program 
An assembly language program, written by the user to ‘converse’ or communicate 
with one or more communicating application programs on OS/3 remote hosts in a 
DDP environment, furnished with the OS/3 DDP file access facility. See Section 9. 


BEQ 
A parameter of the DMCTL imperative, which indicates the primary program 
wishes to bequeath primary status to the surrogate program. The primary program 
becomes the surrogate program after the solicited response has been received from 
the surrogate. 


C 


catalog 
An online directory of information containing file names with their passwords that 
enables easy access to the files and also restricts files to certain users. 


CDM 
See consolidated data management. 


centralized data processing (computer) system 
A method of data processing in which a large processing unit accommodates the 
varied needs of many users. The centralized computer may have many 
nonintelligent terminals and peripherals. 
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command 
An action performed on a computer. 





command analyzer 
The part of the DDP software that analyzes your commands and forwards them for 
processing. 


compiled job 
A series of expanded job control statements in a system library that can be | 
executed immediately. | 


complex conversation 
A 2-way alternating communications discipline whereby primary and surrogate 
programs may send and receive data. The primary and surrogate programs may 
reverse statuses. A primary program can also communicate with more than one 
surrogate program. 


consolidated data management 
The name of the System 80 data management system. Also available as an option 
on Series 90. 





conversation 
An exchange of information between two or more communicating programs 
conducted via CDM __ program-to-program imperative macroinstructions. 
Conversations may be simple or complex. & 





D 


data base 
A collection of data fundamental to an organization. 


data handling 
The ability to access data on a remote host using programs on the local host. 


DDP 
See distributed data processing. 


DDP command analyzer 
See command analyzer. 
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& DDP file access facility 
A SPERRY UNIVAC DDP program facility composed of a; 


= remote file processing component — whereby you can access and process files 
residing on remote OS/3 systems; and 


™ = =§=©program-to-program communications component — whereby you can write 
application programs that can initiate data, jobs, and control information on a 
remote host or hosts. 


DDP system 
See distributed data processing system. 


DDP transfer facility 
A SPERRY UNIVAC DDP program facility, which allows workstations and terminal 
operators to copy files and libraries from one system in a network to another 
system in a network, and submit jobs to other systems in the network. The files 
may reside on the system to which the operator is connected (local or home 
system), or they may reside on some other system in the network (remote 
system). 


DEACT 
Parameter of the DMCTL imperative issued by the primary program to provide data, 
& to and solicit a response from, the surrogate program in conjunction with a request 
to terminate the conversation. The surrogate program may accept ((REPLY (END)) or 
reject (REPLY) the terminating request when sending the response message. 





decentralized data processing (computer) system 
A method whereby several independent computers exist within an organization but 
are not electronically connected. 


defined record management 
The facility of IMS to access a defined file. 


demand mode interface 


The ICAM system interface that supports both distributed data processing and all 
OS/3 interactive services. 


destination file 
In a DDP system, the file into which another file is being copied. 


destination-host-id (with the DDP file access facility) 
Is one to four alphanumeric characters naming the host to receive the data. If 


omitted, DDP assumes the destination file is on your local host. See 7.1.2, 8.3.2 
and 8.4.1. 
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destination (with the DDP file access facility) 
Is an extension of the user-id node used in the DDP file access facility, with the 
format: 


destination:: =[host—id:]user-id 


Host-id is a one to four alphanumeric character identification of the computer on 
which you wish your job to be executed. The host-id is optional and defaults to the 
local host, that is the host computer on which the job is executing. The generic 
host-id, $HOST, specifies that the host-id is the originator or master. 


display messages 
Information about a job being executed, displayed on a console or terminal screen. 


distributed communications architecture (DCA) 
The SPERRY UNIVAC architecture that draws together all aspects of the 
communication products by defining a set of logical concepts and a set of rules 
(protocols and interfaces) and guidelines to be used in applying the concepts in the 
design of hardware, software, and network products. 


distributed data processing system 
A configuration of independent computers joined in a peer relationship. 


DMI 
See demand mode interface. 


E 


element 
In OS/3, a discrete part of a module in a program library file. ln DDP commands, 
however, an element is a module. 


element type 
Thé kind of code that the elements are written in, such as symbolic (source code) 
or absolute (load code). See also element. 


encoding 


The converting of data through use of a code so that it can be reconverted to its 
original form. 
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F 


file-id 
The complete name by which a file is identified. In DDP, the file-id must include the 
file name, and may also include the module name, read and write passwords, 
volume, and element type, in this format: 


‘[module-name], filename[([read-passwrd]/write-passwrd])],[vol],[element]' 

file name 
From 1 to 44 alphanumeric characters identifying your file when it resides on disk, 
and 1 to 17 alphanumeric characters for tape files and logical files (spool files). 


H 


help screens 


A display of how information and additional help can be obtained for the DDP 
commands. 


heterogeneous DDP system 
A DDP system in which the various hosts use different operating systems. 


hierarchical relationship 
An arrangement of hosts so that there is a different rank among them. 


homogeneous DDP system 
A DDP system in which the various hosts all use the same operating system. 


host 
An independent computer attached to a DDP system. 


host-id 
The identifying name of your host. In DDP, it is the same as the node-id you 
specify in the REMOTE parameter of your LOCAP macroinstruction in your ICAM 
network definition. If host-id is omitted, the local host is assumed. See 7.1.2, 
10.4.1 and the individual commands and imperatives where host-id is used for 


particular specifications. Also, see the variations: destination, local and originating 
host-ids. 
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ICAM 
Integrated communications access method. A generalized software package for 
OS/3 communications that gives you multiple levels of interface to remote devices. 


IMS DDP transaction processor facility (IMS DDP) 
A SPERRY UNIVAC IMS DDP transaction processor facility, which enables 
workstations and terminal operators to process IMS transaction at a remote OS/3 
computer. Multithreaded IMS systems are required at both the local and remote 
sites. IMS can route a transaction to a remote system by: 


m transaction directory routing; 
m transaction program routing; or 
| transaction operator routing 


indexed file 
A file accessed according to one or more index keys (for example, IRAM or MIRAM 
files). 


information management system (IMS) 
A software product facilitating the development and _ installation of online, 
transaction-oriented data base management applications under OS/3. 


interactive services 
A collection of commands and system programs that enables you to prepare, run, 
and control jobs and to perform system housekeeping routines easily and quickly 
from a workstation. 


J 


jobname 
Is one to eight alphanumeric characters naming the job that the DDP SUBMIT FILE 
command returned to you. DDP assumes the job is one the local host. See 8.2.6.3. 


jproc 
A series of job control statements stored in a library that can be executed by a 
simple job control statement. (Same as ‘‘proc”’ or ‘‘procedure’’.) 
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® . 


library file 
A file consisting of a collection of program modules. 


local host 
A one to four alphanumeric identifying the computer you are using at your site. see 
the command using the local host-id for particular specifications at 8.3.1, 8.3.3 and 
S54. 


LOCAP (LOCal APplication) file 
The file that is necessary to permit program-to-program transfer, whether local or 
remote, and supplies the name and type of program that other applications may 
address for access. 


M 


macro or macroinstruction 
A source statement in an assembler program that is converted into many 
@ assembler source statements to do a particular function (for example, OPEN or 





CLOSE). 


master-slave relationship 
A communications connection in which one computer completely controls the data 
sending and receiving functions. 


message 
Consists of some arbitrary amount of information whose beginning and end are 
defined or implied, and is transmitted from one program to another program in a 
DDP network. 


module 
A part of a library file that is accessible by name as a unit. 


N 


network 
The total collection of physical entities joined in a data communications system 
(nodes, network processors, terminals, etc). 
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nine-thousand remote (NTR) 
A software utility program that controls data transmission to allow the SPERRY 
UNIVAC 90/30 System to be used as a terminal to the SPERRY UNIVAC 1100 
System. 





nonencoded characters 
Standard codes (such as EBCDIC or ASCII) are made up of bit patterns. There are 
more possible bit patterns than are actually used in these codes. Some users alter 
their computers to recognize patterns that are not part of the standard code. These 
unique bit patterns are called nonencoded characters. 


NTR 
See nine-thousand remote. 


O 


originating file 
In DDP, the file from which a copy is being made. 


originating host-id 
Is one to four alphanumeric characters naming the originating host. Used with the 
DDP SUBMIT FILE command, it names the job control stream file location. If 
HOST-ID is omitted, the system assumes the file is on your local host. See 8.3.2 
and 8.4.1. 





P 


password 
One to six alphanumeric characters you must specify to read a file (read-passwrd) 
or write to a file (write-passwrd). Passwords are opitonal parts of the file-id. They 
are used only with cataloged files. 


primary host 
The originating host in a DDP system. 


primary program 
The initiating part of a pair of application programs in the program-to-program 
component of the DDP file access facility. See surrogate program for the other part 
of the communicating pair. 


procedure/proc 
See jproc. 
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program-to-program communication 
A component of the DDP file access facility whereby you can write a BAL program 
that can initiate and carry on a “‘conversation’’ with another BAL surrogate program 
at a remote OS/3 host. The communicating programs must reside on different 
hosts in the DDP network. 


protocol 
A set of rules defining the structure, content, sequencing procedures, and error 
detection and recovery techniques for the transmission of data. Also used to 
establish, maintain, and control communications between two corresponding levels 
in a level hierarchy. Normally implies the sending and receiving of unique command 
and response messages or message headers. 


R 


read password 
See password. 


relative file 
A file you may access either record-by-record or by the relative number of the 
logical record within the file. 


relocatable code 
Object code. 


remote file processing 
A component of the DDP file access facility whereby you can access and process 
disk files residing on remote OS/3 systems in your DDP network. 


remote host 
The computer geographically separated from you to which you are electronically 
connected. 


ring structure 
The joining of hosts in a circle so that each is connected to two others. 


S 


screen format 


A form displayed on a video terminal used to input data to a program or to output 
data from a program. 


secondary host 
The destination host in a DDP system. 
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sequential file 
A file you access record-by-record, according to the order of the records in the file. 


simple conversation 
A 1-way-only communications discipline whereby the primary program is only 
allowed to send and the surrogate program is only allowed to receive. Only one 
primary program and one surrogate program is involved and that relationship 
remains for the duration of the conversation. 


spooling 
The process by which the central processor reads and writes records to or from a 
high-speed storage device rather than a slower device. 


stand-alone processing 
The ability of a computer to process data with no connection to any other 
computer. 


star structure 
The joining of hosts so all hosts are connected to one central host. 


surrogate program 
A surrogate user application program that is one part of a pair of programs used 
with the DDP file access facility. See primary program for the other part of the 
program pair. However, the two programs can exchange statuses via the BEQueath 
parameter of the DMCTL imperative. 


symbolic code 
Source code. 


system 
See distributed data processing system. 


T 


Telcon 
A SPERRY UNIVAC communications system designed to implement network 
communications in a wide variety of applications. The Telcon system is based on a 
unified family of hardware and software components that implement the distributed 
communications architecture. The principal hardware component is the distributed 
communications processor. 


terminal 
A point in a network where data can either enter or leave. Normally operator 
oriented in that it provides for human interpretable input/output media. 
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transaction directory routing 
A routing method of the IMS DDP transaction processor facility whereby the 
terminal operator routes a transaction via a transaction code that identifies a 
transaction at a particular remote system. See transaction operator writing and 
transaction program routing. 


transaction operator routing 
A routing method of the IMS DDP processor transaction facility whereby the 
terminal operator routes a transaction via a transaction code with a_ special 
character that routes the transaction to a particular remote system. See transaction 
directory routing and transaction program routing. 


transaction processing 
The use of an information management system to request information or to change 
records, and to receive a response. Each transaction involves one input request 
from a terminal followed by one output response from a host. DDP transaction 
processing involves the use of information management systems across two or 
more hosts. 


transaction program routing 
A routing method of the IMS DDP transaction processor facility whereby the 
terminal operator initiates a transaction at the local IMS system. The COBOL or 
basic assembly language action program sends a message that initiates a 
transaction at the remote system. See transaction directory routing and transaction 
operator routing. 


tree structure 
The joining of hosts so that each is connected to at least one other host but may 
in addition be connected to others. 


two-way alternating communication 
A DDP file access facility communications discipline between pairs that provides a 
request/response exchange to coordinate data transfer. A sense of primary and 
surrogate program is maintained. See complex conversation. 


U 


undefined file 
Any type of file except a library file containing source (symbolic) code. 


UNIQUE (uniform inquiry update element) 
An easy-to-use inquiry language that lets you display data and update your files by 
entering commands from the terminal. A set of IMS-supplied action programs 
processes these UNIQUE commands. 


user-id 
Is the one to six alphanumeric characters identifying you as a user to the host. 
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V 


volume table of contents (VTOC) 
A directory written on your disk volume that lists the addresses and other 
information about the files on that volume. 


WwW 


work order number 
A reference number assigned to each command entered into the DDP software. 


work order request 
Any command you enter into the DDP software. Some messages use this term 
when they're referring to the command you entered immediately preceding this 
message. 


workstation 
Any terminal, consisting of a CRT display and typewriter-like keyboard, that you 
use to access the interactive services. 


write password 
See password. 
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Tape, use with DDP 

Telcon, use with DDP 
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